Lazarus

Programming => General => Topic started by: Ash on March 03, 2021, 06:03:37 pm

Title: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Ash on March 03, 2021, 06:03:37 pm
Hi.
First time poster, long time lurker.

I'm getting a runtime error in my program by a call to EnumChildWindows.
Targetting x86_64 gives me a SIGSEGV error. Targetting i386 gives me a SIGILL error.

Tested with: Lazarus 2.0.12 + FPC 3.2.0 (x86_64-win64-win32/win64) and Lazarus 2.0.8 + FPC-3.0.4 (x86_64-win64-win32/win64).
Tested On: Windows 10 Pro 64bit and Windows 7 Pro 64bit.

Test code below produces these errors, for me, with FPC.
However, it works fine when tested with Delphi 2007 and C++, C#, VB (Visual Studio 2019).
Code: Pascal  [Select][+][-]
  1. program EnumChildWindows_test;
  2.  
  3. {$mode objfpc}
  4.  
  5. uses windows;
  6.  
  7. function EnumProc(hWnd: HWND; lParam: LPARAM): BOOL stdcall;
  8. begin
  9.   if (hWnd <> 0) then
  10.     EnumChildWindows(hWnd, ENUMWINDOWSPROC(@EnumProc), hWnd);
  11. (* Also of note:  EnumChildWindows doesn't always call its Callback function. *)
  12.  
  13.   result := true;
  14. end;
  15.  
  16. begin
  17.   EnumWindows(ENUMWINDOWSPROC(@EnumProc), 0);
  18. end.
  19.  

Hoping someone can point out if I'm doing it wrong or maybe perhaps a bug in FPC.

Thank you.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: balazsszekely on March 03, 2021, 07:02:43 pm
Enumerate all top level windows:
Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses
  6.   Windows;
  7.  
  8. var
  9.   wList: String;
  10.  
  11. function EnumWindowsProc(hWnd: HWND; {%H-}lParam: LPARAM): BOOL stdcall;
  12. var
  13.   Title: array[0..255] of Char;
  14.   ClassName: array[0..255] of Char;
  15. begin
  16.   GetWindowText(hWnd, Title, 255);
  17.   GetClassName(hWnd, ClassName, 255);
  18.   if IsWindowVisible(hWnd) then
  19.     wList := wList + String(Title) + ' - ' + String(ClassName) + sLineBreak;
  20.   Result := True;
  21. end;
  22.  
  23. begin
  24.   wList := '';
  25.   EnumWindows(@EnumWindowsProc, 0);
  26.   MessageBox(0, PChar(wLIst), PChar('Top level windows("Title" - "ClassName")'), 0);
  27. end.


Create a window and a button with pure api, then enumerate all top level windows on button click:
Code: Pascal  [Select][+][-]
  1. program EnumWindow;
  2.  
  3. {$mode Delphi}
  4.  
  5. uses windows;
  6.  
  7. var
  8.   wClass: TWndClass;
  9.   hInst: HWND;
  10.   hWindow: HWND;
  11.   hButton: HWND;
  12.   Msg: TMSG;
  13.   wList: String;
  14.  
  15. function EnumWindowsProc(hWnd: HWND; {%H-}lParam: LPARAM): BOOL stdcall;
  16. var
  17.   Title: array[0..255] of Char;
  18.   ClassName: array[0..255] of Char;
  19. begin
  20.   GetWindowText(hWnd, Title, 255);
  21.   GetClassName(hWnd, ClassName, 255);
  22.   if IsWindowVisible(hWnd) then
  23.     wList := wList + String(Title) + ' - ' + String(ClassName) + sLineBreak;
  24.   Result := True;
  25. end;
  26.  
  27. procedure DoOnclick;
  28. begin
  29.   wList := '';
  30.   EnumWindows(@EnumWindowsProc, 0);
  31.   MessageBox(hWindow, PChar(wLIst), PChar('Top level windows("Title" - "ClassName")'), 0);
  32. end;
  33.  
  34. procedure DoDestroy;
  35. begin
  36.   UnRegisterClass('My class', hInst);
  37.   ExitProcess(hInst);
  38. end;
  39.  
  40. procedure DoPaint;
  41. begin
  42.   //
  43. end;
  44.  
  45. function WindowProc(hWnd, Msg, wParam, lParam: DWord): Longint; stdcall;
  46. begin
  47.   Result := DefWindowProc(hWnd, Msg, wParam, lParam);
  48.   case Msg of
  49.      WM_COMMAND: if lparam = hButton then DoOnClick;
  50.      WM_DESTROY: DoDestroy;
  51.      WM_PAINT: DoPaint;
  52.   end;
  53. end;
  54.  
  55. begin
  56.   hInst := GetModuleHandle(nil);
  57.   with wClass do
  58.   begin
  59.     hIcon := LoadIcon(hInst, 'MAINICON');
  60.     lpfnWndProc:= @WindowProc;
  61.     hInstance := hInst;
  62.     hbrBackground := COLOR_BTNFACE;
  63.     lpszClassName := 'My class';
  64.   end;
  65.   RegisterClass(wClass);
  66.   hWindow := CreateWindow('My class', 'My main window', WS_SYSMENU or WS_VISIBLE or WS_SIZEBOX, 10, 10, 400, 300, 0, 0, hInst, nil);
  67.   hButton := CreateWindow('Button', 'Enum windows', WS_CHILD or BS_PUSHLIKE or BS_TEXT or WS_VISIBLE, 275, 125, 125, 24, hWindow, 0, hInst, nil);
  68.   SetFocus(hButton);
  69.   while(GetMessage({%H-}Msg, hWindow, 0, 0))do
  70.   begin
  71.     TranslateMessage(Msg);
  72.     DispatchMessage(Msg);
  73.   end;
  74. end.


The second example is interesting because LCL is not needed, the exe size is very small(69KB). The only issue with this approach is productivity, the lack of productivity to be more precise. :)
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Remy Lebeau on March 03, 2021, 07:08:34 pm
Enumerate all top level windows:
...
Create a window and a button with pure api, then enumerate all top level windows on button click:
...

In no way whatsoever does this even remotely try to answer Ash's question about why calling EnumChildWindows() inside of a EnumWindows() callback is crashing.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Remy Lebeau on March 03, 2021, 07:12:45 pm
I'm getting a runtime error in my program by a call to EnumChildWindows.

Off-hand, aside from the unnecessary type-casts, I see nothing wrong with the code.  Do you have the same problem if you use separate callbacks for EnumWindows() and EnumChildWindows()?

Code: Pascal  [Select][+][-]
  1. program EnumChildWindows_test;
  2.  
  3. {$mode objfpc}
  4.  
  5. uses windows;
  6.  
  7. function EnumChildProc(hWnd: HWND; lParam: LPARAM): BOOL stdcall;
  8. begin
  9.   EnumChildWindows(hWnd, @EnumChildProc, 0);
  10.   Result := TRUE;
  11. end;
  12.  
  13. function EnumProc(hWnd: HWND; lParam: LPARAM): BOOL stdcall;
  14. begin
  15.   EnumChildWindows(hWnd, @EnumChildProc, 0);
  16.   Result := TRUE;
  17. end;
  18.  
  19. begin
  20.   EnumWindows(@EnumProc, 0);
  21. end.
  22.  
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: marcov on March 03, 2021, 07:25:59 pm
With 64-bit Windows target, try FPC 3.2.0, there were quite some 64-bit fixes to the windows headers in 3.2.0
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: balazsszekely on March 03, 2021, 07:43:33 pm
In no way whatsoever does this even remotely try to answer Ash's question about why calling EnumChildWindows() inside of a EnumWindows() callback is crashing.
Ok. I got carried away and I forget to add the EnumChildWindow part. Saying that my post has nothing to do with Ash's question is a gross exaggeration. Anyways here is the complete answer. Tested with Lazarus Trunk/FPC 3.2.0(64 bit), works fine. Regarding the unnecessary typecast, it's a bad habit from pre- FPC 3.0.0 era. 


Code: Pascal  [Select][+][-]
  1. program EnumWindow;
  2.  
  3. {$mode Delphi}
  4.  
  5. uses windows;
  6.  
  7. var
  8.   wClass: TWndClass;
  9.   hInst: HWND;
  10.   hWindow: HWND;
  11.   hButton: HWND;
  12.   Msg: TMSG;
  13.  
  14. function EnumChildWindowsProc(hWnd: HWnd; lParam: LPARAM): Bool; stdcall;
  15. var
  16.   Title: array[0..255] of Char;
  17. begin
  18.   GetWindowText(hWnd, Title, 255);
  19.   if IsWindowVisible(hWnd) and (String(Title) <> '') then
  20.     MessageBox(0, PChar(Title), PChar('Child window'), 0);
  21.   if GetWindow(hWnd, GW_CHILD) > 0 then
  22.     Enumchildwindows(hWnd, @EnumChildWindowsProc, 0);
  23.   Result := True;
  24. end;
  25.  
  26. function EnumWindowsProc(hWnd: HWND; {%H-}lParam: LPARAM): BOOL stdcall;
  27. var
  28.   Title: array[0..255] of Char;
  29. begin
  30.   GetWindowText(hWnd, Title, 255);
  31.   if IsWindowVisible(hWnd) and (String(Title) <> '') then
  32.     MessageBox(0, PChar(Title), PChar('Top window'), 0);
  33.   EnumChildWindows(hWnd, @EnumChildWindowsProc, 0);
  34.   Result := True;
  35. end;
  36.  
  37. procedure DoOnclick;
  38. begin
  39.   EnumWindows(@EnumWindowsProc, 0);
  40. end;
  41.  
  42. procedure DoDestroy;
  43. begin
  44.   UnRegisterClass('My class', hInst);
  45.   ExitProcess(hInst);
  46. end;
  47.  
  48. procedure DoPaint;
  49. begin
  50.   //
  51. end;
  52.  
  53. function WindowProc(hWnd, Msg, wParam, lParam: DWord): Longint; stdcall;
  54. begin
  55.   Result := DefWindowProc(hWnd, Msg, wParam, lParam);
  56.   case Msg of
  57.      WM_COMMAND: if lparam = hButton then DoOnClick;
  58.      WM_DESTROY: DoDestroy;
  59.      WM_PAINT: DoPaint;
  60.   end;
  61. end;
  62.  
  63. begin
  64.   hInst := GetModuleHandle(nil);
  65.   with wClass do
  66.   begin
  67.     hIcon := LoadIcon(hInst, 'MAINICON');
  68.     lpfnWndProc:= @WindowProc;
  69.     hInstance := hInst;
  70.     hbrBackground := COLOR_BTNFACE;
  71.     lpszClassName := 'My class';
  72.   end;
  73.   RegisterClass(wClass);
  74.   hWindow := CreateWindow('My class', 'My main window', WS_SYSMENU or WS_VISIBLE or WS_SIZEBOX, 10, 10, 400, 300, 0, 0, hInst, nil);
  75.   hButton := CreateWindow('Button', 'Enum windows', WS_CHILD or BS_PUSHLIKE or BS_TEXT or WS_VISIBLE, (400 - 125) div 2, 125, 125, 24, hWindow, 0, hInst, nil);
  76.   SetFocus(hButton);
  77.   while(GetMessage({%H-}Msg, hWindow, 0, 0))do
  78.   begin
  79.      TranslateMessage(Msg);
  80.      DispatchMessage(Msg);
  81.   end;
  82. end.
  83.  
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Ash on March 03, 2021, 07:58:41 pm
Off-hand, aside from the unnecessary type-casts, I see nothing wrong with the code.  Do you have the same problem if you use separate callbacks for EnumWindows() and EnumChildWindows()?

Unless I include directive {$T+}, the compiler will give me the 'Incompatible type' error. (EDIT: Still need to use typecasts on some things even after including {$T+}.)
Yes, I get the same errors. Tried it before creating the thread. By the way, does it work for you?

--

With 64-bit Windows target, try FPC 3.2.0, there were quite some 64-bit fixes to the windows headers in 3.2.0

I'm using the latest version of the compiler which is fpc v3.2.0.

--

Just noticed that if I use {$mode delphi} instead of {$mode objfpc} i don't get the runtime errors. I guess i can live with that.
The irony of it is a little funny though (for me anway) because I'm converting an old project I wrote in Delphi 7 to Free Pascal and I have to use the Delphi mode for it to work.

So is something broken on my end or with mode objfpc?

--

Thanks for the responses.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Ash on March 03, 2021, 08:03:36 pm
Ok. I got carried away and I forget to add the EnumChildWindow part. Saying that my post has nothing to do with Ash's question is a gross exaggeration. Anyways here is the complete answer. Tested with Lazarus Trunk/FPC 3.2.0(64 bit), works fine. Regarding the unnecessary typecast, it's a bad habit from pre- FPC 3.0.0 era. 

Code: Pascal  [Select][+][-]
  1. program EnumWindow;
  2.  
  3. {$mode Delphi}
  4.  
  5. uses windows;
  6.  
  7. var
  8.   wClass: TWndClass;
  9.   hInst: HWND;
  10.   hWindow: HWND;
  11.   hButton: HWND;
  12.   Msg: TMSG;
  13.  
  14. function EnumChildWindowsProc(hWnd: HWnd; lParam: LPARAM): Bool; stdcall;
  15. var
  16.   Title: array[0..255] of Char;
  17. begin
  18.   GetWindowText(hWnd, Title, 255);
  19.   if IsWindowVisible(hWnd) and (String(Title) <> '') then
  20.     MessageBox(0, PChar(Title), PChar('Child window'), 0);
  21.   if GetWindow(hWnd, GW_CHILD) > 0 then
  22.     Enumchildwindows(hWnd, @EnumChildWindowsProc, 0);
  23.   Result := True;
  24. end;
  25.  
  26. function EnumWindowsProc(hWnd: HWND; {%H-}lParam: LPARAM): BOOL stdcall;
  27. var
  28.   Title: array[0..255] of Char;
  29. begin
  30.   GetWindowText(hWnd, Title, 255);
  31.   if IsWindowVisible(hWnd) and (String(Title) <> '') then
  32.     MessageBox(0, PChar(Title), PChar('Top window'), 0);
  33.   EnumChildWindows(hWnd, @EnumChildWindowsProc, 0);
  34.   Result := True;
  35. end;
  36.  
  37. procedure DoOnclick;
  38. begin
  39.   EnumWindows(@EnumWindowsProc, 0);
  40. end;
  41.  
  42. procedure DoDestroy;
  43. begin
  44.   UnRegisterClass('My class', hInst);
  45.   ExitProcess(hInst);
  46. end;
  47.  
  48. procedure DoPaint;
  49. begin
  50.   //
  51. end;
  52.  
  53. function WindowProc(hWnd, Msg, wParam, lParam: DWord): Longint; stdcall;
  54. begin
  55.   Result := DefWindowProc(hWnd, Msg, wParam, lParam);
  56.   case Msg of
  57.      WM_COMMAND: if lparam = hButton then DoOnClick;
  58.      WM_DESTROY: DoDestroy;
  59.      WM_PAINT: DoPaint;
  60.   end;
  61. end;
  62.  
  63. begin
  64.   hInst := GetModuleHandle(nil);
  65.   with wClass do
  66.   begin
  67.     hIcon := LoadIcon(hInst, 'MAINICON');
  68.     lpfnWndProc:= @WindowProc;
  69.     hInstance := hInst;
  70.     hbrBackground := COLOR_BTNFACE;
  71.     lpszClassName := 'My class';
  72.   end;
  73.   RegisterClass(wClass);
  74.   hWindow := CreateWindow('My class', 'My main window', WS_SYSMENU or WS_VISIBLE or WS_SIZEBOX, 10, 10, 400, 300, 0, 0, hInst, nil);
  75.   hButton := CreateWindow('Button', 'Enum windows', WS_CHILD or BS_PUSHLIKE or BS_TEXT or WS_VISIBLE, (400 - 125) div 2, 125, 125, 24, hWindow, 0, hInst, nil);
  76.   SetFocus(hButton);
  77.   while(GetMessage({%H-}Msg, hWindow, 0, 0))do
  78.   begin
  79.      TranslateMessage(Msg);
  80.      DispatchMessage(Msg);
  81.   end;
  82. end.
  83.  

This code does indeed work, but only when using {$mode delphi}. It still produces runtime errors when using {$mode objfpc}.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: ASBzone on March 03, 2021, 08:05:11 pm
Just noticed that if I use {$mode delphi} instead of {$mode objfpc} i don't get the runtime errors. I guess i can live with that.
The irony of it is a little funny though (for me anway) because I'm converting an old project I wrote in Delphi 7 to Free Pascal and I have to use the Delphi mode for it to work.

So is something broken on my end or with mode objfpc?

{$mode delphi} is the mode to use for maximum Delphi compatibility.  {$mode objfpc} behaves differently in some areas for a variety of reasons, none of which means that this is a broken mode.


Sometimes a feature already exists, and making it Delphi compatible means running in a mode where it will behave differently than it would otherwise.   

For instance:  https://www.freepascal.org/docs-html/prog/progse74.html
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: balazsszekely on March 03, 2021, 08:09:12 pm
@Ash

Go with {$mode delphi} as @ASBzone suggested, nothing wrong with that.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Ash on March 03, 2021, 08:20:38 pm
I will be using {$mode delphi} for that particular unit in my project.
I don't think this is a 'feature' issue between the two modes. Calling a WinAPI function should behave the same in either mode but causes runtime errors in the objfpc mode. Am I missing something here? I'm just curious if there's a problem on my end or is there some bug in the compiled code when using the objfpc mode. Which doesn't make sense to me anyway so i'm thinking something is broken on my end.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: ASBzone on March 03, 2021, 08:49:15 pm
I will be using {$mode delphi} for that particular unit in my project.
I don't think this is a 'feature' issue between the two modes. Calling a WinAPI function should behave the same in either mode but causes runtime errors in the objfpc mode. Am I missing something here? I'm just curious if there's a problem on my end or is there some bug in the compiled code when using the objfpc mode. Which doesn't make sense to me anyway so i'm thinking something is broken on my end.

There's obviously a difference in the code path that has an impact on your app.

It might take a little bit of digging to determine if it is a bug in FPC, or the natural implication of that code path on some other aspect of your code.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: 440bx on March 03, 2021, 08:56:31 pm
so i'm thinking something is broken on my end.
and you are right to think that something is broken on your end.  The problem resides in the fact that you are using the same callback routine for both EnumWindows and EnumChildWindows.  That causes your callback routine to be called recursively for every child window.  That API was _not_ designed to be called recursively (see MSDN.)    EnumChildWindows will list all the children, grandchildren and grandgrand...grandchildren without having to call it for every child.  The fact that it is being called recursively is conceptually incorrect and it is actually surprising that doing so works in some cases (I'm taking your word for it that it worked with Delphi using the code you posted.)

Attached to this post you'll find an example that lists all windows in the system (those returned by EnumWindows which unfortunately excludes the desktop window) and their children.  Notice that the example does _not_ cause EnumWindows and/or EnumChildWindows to be called recursively.  Since, it is often convenient to show the "genealogy" of a window, for that purpose, the example uses GetAncestor, IOW, it doesn't try to establish the genealogy using recursion.

Also, the example works with both FPC 32 and 64 bit as well as with Delphi (tested with Delphi 2 only) no "mode whatever" needed.

HTH.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Remy Lebeau on March 04, 2021, 12:37:21 am
The problem resides in the fact that you are using the same callback routine for both EnumWindows and EnumChildWindows.  That causes your callback routine to be called recursively for every child window.  That API was _not_ designed to be called recursively (see MSDN.)    EnumChildWindows will list all the children, grandchildren and grandgrand...grandchildren without having to call it for every child.  The fact that it is being called recursively is conceptually incorrect and it is actually surprising that doing so works in some cases (I'm taking your word for it that it worked with Delphi using the code you posted.)

Good catch!  I forgot about that detail.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: 440bx on March 04, 2021, 01:40:20 am
Good catch!  I forgot about that detail.
It's a very easy to forget detail because its description (EnumChildWindows) doesn't make that clear at all.  Instead, it is only in the "remarks" section that they point it out.

Another interesting comment in the remarks section implies that the API is a "snapshot" type of function, i.e, it builds a window list upfront then verifies that the window hasn't been destroyed before returning it.  The fact that it builds the window list upfront also explains why it won't return any child window that was created during the enumeration.

NOTE: disassembly of the API confirms that it is a snapshot type function as the remarks section implies.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: balazsszekely on March 04, 2021, 07:53:19 am
@440bx
EnumChildWindows aside, your demo project is a very nice example of API programming. I like the way you build up everything from scratch(Memu, Listbox, About box, etc.),  it brings me back to the 90' and Visual Studio 6.0. :) I think every beginner should study your code, before using the power of form designers like Lazarus and Delphi.
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. 

Thx for sharing.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: marcov on March 04, 2021, 11:30:59 am
I will be using {$mode delphi} for that particular unit in my project.
I don't think this is a 'feature' issue between the two modes. Calling a WinAPI function should behave the same in either mode

But passing a callback is different in both modes. Objfpc requires a @ to be added.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Ash on March 04, 2021, 11:50:04 am
That API was _not_ designed to be called recursively (see MSDN.)
I already knew about this.
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.

I apologise for the badly simplified snippet of code I provided in my original example.
I will provide another snippet with a few extra lines of my code but still omit the unnecessary stuff to keep it legible.
Code: Pascal  [Select][+][-]
  1. program EnumChildWindows_test;
  2.  
  3. {$mode objfpc} // Crashes in this mode.
  4. //{$mode delphi} // Successful in this mode.
  5.  
  6. uses windows;
  7.  
  8. function EnumProc(hWnd: HWND; lParam: LPARAM): BOOL stdcall;
  9. begin
  10.   if (hWnd <> 0) then
  11.   begin
  12.     if (lParam = 0) then
  13.     begin
  14. // This block only gets executed by EnumWindows.
  15.  
  16.       { code here to collect info for parent windows }
  17.  
  18.       EnumChildWindows(hWnd, ENUMWINDOWSPROC(@EnumProc), hWnd);
  19.     end
  20.     else
  21.     begin
  22. // This block only gets executed by EnumChildWindows.
  23. // No recursive EnumChildWindows calls.
  24.  
  25.       { code here to collect info for child windows }
  26.     end;
  27.   end;
  28.  
  29.   result := true;
  30. end;
  31.  
  32. begin
  33. // I pass a zero to lParam and test for it in EnumProc to prevent recursive calls to EnumChildWindows. Yes, it's ugly.
  34.   EnumWindows(ENUMWINDOWSPROC(@EnumProc), 0);
  35. end.
  36.  
I know this way of doing it is kind of illegible. I wrote it two decades ago. I don't even remember why I did things a certain way two years ago, much less twenty years.
If I split the callback functions into two like in your example, it works fine. I'm fine with that. Or i can just use the Delphi compatibility mode. Which is also fine.
However. Am I the only person that is curious as to why EnumChildWindows (when used in the way like the code above) crashes with {$mode objfpc}, but it works as intended with {$mode delphi} in FPC as well as in Delphi(7, 2007), c++, c# and VB?
I may just be completely wrong about all of this. Please don't let this cat be a victim of its own curiosity.
If nobody else is curious or I'm just wrong, then case closed, question solved, close thread. I'm just happy to finally get it working after hours of head scratching last night.

If you percieve this as a rant, I assure you it is not. I've been using Lazarus+FPC for over ten years and I love it. You lot that create this stuff are incredible.

Cheers.
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: balazsszekely on March 04, 2021, 12:30:05 pm
@Ash
Quote
Am I the only person that is curious as to why EnumChildWindows (when used in the way like the code above) crashes with {$mode objfpc}, but it works as intended with {$mode delphi} in FPC as well as in Delphi(7, 2007), c++, c# and VB?
No I'm also curious, but the thing is my previous example does not crash with {$mode ObjFPC}{$H+}. Please test attached project.   
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: Ash on March 04, 2021, 12:48:36 pm
No I'm also curious, but the thing is my previous example does not crash with {$mode ObjFPC}{$H+}. Please test attached project.

I have already acknowledged this in my previous post.
If I split the callback functions into two like in your example, it works fine.

I'm just curious as to why {$mode objfpc} can't handle it when "I DID IT MY WAY!" oh no. I have that song in my head now. :D
Title: Re: WinAPI | EnumChildWindows causes SIGSEGV/SIGILL
Post by: 440bx on March 04, 2021, 04:52:18 pm
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. :)

TinyPortal © 2005-2018