dummzeuch

If I remember correctly, there was a post here on DP-en about this, right when the forum opened.

Any hints on my question 2?

https://github.com/FMXExpress/UnofficialDelphiPRAXiS

Ouch, too simple.

You won't notice if the text gets too small to read.

The exit doesn't make sense, but it is quite possible that it is left from a previous version of the code that didn't re-raise the exception. (Or it's just from somebody who didn't understand the way exceptions work.)

You can simply hold down the Ctrl key and move a dockable window like any other window.

Sorry, to answer a rhetorical question (again), but: There are types of exceptions I usually don't care about and are therefore disabled in the debugger, e.g. EAbort. Sometimes, if there is a problem with these in a particular part of the code, I want to catch them and follow the exception handling further up. But even then I don't want to enable them everywhere else. That's a possible use case for the above construct.

But how do you break there if you disable debugging? The option I was talking about is called "Notify on language exceptions".

It creates a line to place a breakpoint, if you disable stop on exceptions in the debugger.

I did a test with about 2000 points. The result is nearly instant just using a linear search approach (and even using an existing DistanceTo function that includes a sqrt call). Of course that will change once I get into the 100s of thousands (It's O(n^2 after all) but for now I'll stick to the naive approach.

I just got confused because CnWizard uses "vertical first" vs. "horizontal first" differently than I though was correct: Is "vertical first" really this ? And is "horizontal first" really this ? I would have thought it the opposite.

Seen that one too. So it's not my code that's causing it. Good to know.

From docwiki.embarcadero.com/Libraries/en/Data.DB.TDataSet.CopyFields ---------- schnipp --------- Description CopyFields copies the field definition structure of another dataset. CopyFields copies the matching fields in the current records and returns the number of fields copied. For more information, see http://qc.embarcadero.com/wc/qcmain.aspx?d=7768. For another example, see http://community.devexpress.com/forums/p/47463/160009.aspx. ---------- schnapp --------- So, which is it? Or does it do both? This is no great help, especially since the first link results in an timeout error while the second says authorization required. (The Delphi 2007 help was even less helpful: "This is CopyFields, a member of TDataset.") OK, so I checked the sources and wasn't any wiser. From the context in the sources I am currently looking at I guess it does the first, if necessary and then the second: DestDs.Append; DestDs.CopyFields(SrcDs); DestDs.Post; But so far I am only guessing.

Pointers can be really helpful, especially they can improve performance and readability, but they are also dangerous. I spent nearly a day tracking down the reason why the code a former colleague wrote about 5 years ago all of a sudden led to access violations. The code used to work fine, the problem only surfaced when I changed the size of a record. Consider this code ... https://blog.dummzeuch.de/2018/12/11/pointers-are-dangerous/

That would proabbly have worked for the simplified example, but I doubt that it would have caught the problem in the real code. Do you know an analizer that finds this kind of problems? I would like to try it.

Not sure what kind of code analyzer would have spotted that problem. One that flags all pointer types as violation of "good coding practice"? Yes, that would work, but it would also prevent any usage of pointers. Or is there really one that would have found this problem?

I consider this Ptr := @SomeArray[SomeStructure.SomeIndex]; Ptr.bla := 5; Ptr.blub := 10; // and 10 more lines like this as more readable than SomeArray[SomeStructure.SomeIndex].bla := 5; SomeArray[SomeStructure.SomeIndex].blub := 10; // and 10 more lines like this Of course we could always use WITH instead. 😉 Or we could use a list with objects where the pointer is implicit, but then we'd need a lot of boilerplate code. I would have written it differerently, but this is legacy code which I'd rather touch as little as possible (because it will hopefully become redundant shortly).

OK, I'm pretty sure that it only copies the field values and then only for those fields that exist in the target dataset. It does not create new fields, so the description in the OLH is wrong: * CopyFields copies the field definition structure of another dataset. WRONG * CopyFields copies the matching fields in the current records and returns the number of fields copied. Marco Cantu says the same in his Mastering Delphi Update for Delphi 2006 post.

David Hoyle just blogged about this topic (go ahead, read it first but remember to come back. 😉 ) Welcome back. I think he is making two mistakes here (for suitable definitions of “mistake”): ... https://blog.dummzeuch.de/2018/12/10/remembering-an-applications-size-and-position-on-multiple-screens/

That's why I wrote "All the above does not apply to other settings of a program, you might still want to store these in INI files to make them portable." (or for backup). I don't consider the window positions important enough to backup them ("back them up"?). I don't use the registry for anything else though, only for the window positions for exactly that reason. (GExperts is an exception to this rule which I have often considered changing but never came around doing.)

Hm, it just occurred to me, that with roaming profiles, the registry entries are not restricted to the same computer but will move with the user to possibly different computeres with different monitor setups. In the environment I am currently working, we don't use roaming profiles, so I tend to forget.

I just found out what is wrong with my Delphi IDE Explorer in Delphi 10.3 Rio. The symptom is that the Follow Focus option and the Select Active button no longer work in some forms, in particular in the options dialog (Tools -> Options / Run -> Parameters / Project -> Options). The reason is that this dialog now uses the Screen.OnActiveControlChange event itself ... https://blog.dummzeuch.de/2018/12/09/delphi-ide-explorer-is-broken-in-delphi-10-3-rio/

You quoted the whole command line, not just the program path. This is what I meant: ShellExecute(0, nil, 'cmd.exe', PChar('/C ' + AnsiQuotedStr(program_path, Char(34))+ ' -fg'), PChar(program_path), SW_HIDE);

You should only quote the program path rather than the whole command line.