I think every beginner should study your code, before using the power of form designers like Lazarus and Delphi.
Thank you for the kind words.
The only drawback as far as I can see is productivity. When you have a very large project, with hundred or so forms, creating everything with API is time consuming.
I know most people here will disagree with me but, in the long run, I think productivity might actually be higher programming directly to the API than using a framework. The reason I say that is because all frameworks have a number of assumptions or conditions that the code has to meet in order to work with it and, quite often those assumptions or conditions are either not well documented or easy to forget.
When I go about designing the user interface of a program, I think about where in my past programs I've already written code that implements the features I want, I grab the pieces I need then proceed to put them together for the new program. I'm not sure that a framework would make that faster because, at least in my code, I know _exactly_ all the changes needed to make the whole thing work nicely. IOW, there are no hidden dependencies to cause problems (which require time to solve.)
That said, I won't deny being envious sometimes about the ease of dragging one thing or another onto forms and having a program just a few clicks away but, the result doesn't satisfy me for a final result. As I type this, I'm thinking of .net.
Thx for sharing.
My pleasure.
Although, in my opinion, if called recursively it shouldn't cause any crashes unless you have so many windows open that you run out of memory. Happy to be corrected about this though.
It's not reasonable to expect a function that was _not_ designed to be called recursively to operate properly when called recursively. The first reason for that is, a recursive function has to be re-entrant, while a non recursive function does not have to meet that requirement and, if called recursively, the recursive calls will cause its internal data to be corrupted in ways that are hard to predict with consequent results.
In the specific case of EnumChildWindows, that API allocates a block of memory in a heap and saves the pointer in a _global_ variable in user32's data segment. That alone makes it clear that function is not re-entrant, therefore should _not_ be called recursively.
{$mode objfpc} // Crashes in this mode.
//{$mode delphi} // Successful in this mode.
I admit to being somewhat curious too regarding the reason why it _seems_ to work in one mode (delphi) and not in the other but, knowing that the code is inherently wrong greatly subtracts from the desire to spend time to find out why.
OTH, it shouldn't be that hard to find out but it could be tedious. In your code, place a breakpoint at "if (lParam = 0)" and another one at "result := true" and carefully inspect the stack at each break. The most likely cause of the problem is the stack getting somehow messed up. The difference between what happens in one mode and not in the other will probably be visible there.
If you percieve this as a rant, ...
I understand it's not a rant and, I believe curiosity is a good thing but, in general, my desire to satisfy it is much greater if I believe I did everything right than when I know the problem is at least in part caused by my code being incorrect. In those cases, first I correct my code then, if it still fails, I will go out of my way to satisfy my curiosity to determine why it's failing.