Controls inside the form disappear in execution.

[Mr.Madguy]

$(LazarusDir)\lcl\interfaces\win32\Win32WSStdCtrls.pp

No, GroupBoxWindowProc calls Result := WindowProc at the end. What is called? Things are hard to track in WS classes.

[GetMem]

$(LazarusDir)\lcl\interfaces\win32\Win32WSStdCtrls.pp

No, GroupBoxWindowProc calls Result := WindowProc at the end. What is called? Things are hard to track in WS classes.

1. Menu -> Tools -> Configure "Build Lazarus" ..
2. Select Debug Ide, then rebuild IDE
3. Put a breakpoint to(unit Win32WSStdCtrls.pp, function GroupBoxWindowProc):
  Result := WindowProc(Window, Msg, WParam, LParam);
4. When it breaks press F7

[KodeZwerg]

I haven't tried your modifications yet but a GroupBox should react to be able that it can receive focus event, in that case the first "focusable" control inside that GB gets it.
Will your way of doing still let Tabulator key works like before?
exemplary put a edit1 on form (TabOrder (TO) = 0), GroupBox (GB) TO = 1, inside GB another edit2 TO = 0, under that GB another edit3 TO = 2
in theory when starting app and edit1 is focused, press TAB and edit2 is focused again TAB and edit3 is focused again TAB and it start from beginning...

[GetMem]

I haven't tried your modifications yet but a GroupBox should react to be able that it can receive focus event, in that case the first "focusable" control inside that GB gets it.
Will your way of doing still let Tabulator key works like before?
exemplary put a edit1 on form (TabOrder (TO) = 0), GroupBox (GB) TO = 1, inside GB another edit2 TO = 0, under that GB another edit3 TO = 2
in theory when starting app and edit1 is focused, press TAB and edit2 is focused again TAB and edit3 is focused again TAB and it start from beginning...

Yes, everything works fine. I did not find any anomalies so far.

[wp]

Shouldn't we commit it to have a larger test base? If there is an issue with it we could remove the few lines again at any time...

And I think we should have a bugreport for it referring to this discussion to document why this is changed. This makes life much easier if somebody detects a regression some years later...

[dsiders]

@dsiders

I would gladly test... but using what? The original test.zip for post #1 I assume. Is there a patch or diff with the changes that need to be applied to perform the testing?

1. Download, extract then run attached project
2. Click ten times or so inside the TGroupBox, without clicking another control
3. Click a few times the taskbar(the empty part of the taskbar)
4. Click the TGroupBox again
Repeat 2 -> 4 until you see the issue. As mentioned before, there are other ways to reproduce the bug, but I found the above method the easiest.

Once you see the issue:
1. Open: $(LazarusDir)\lcl\interfaces\win32\Win32WSStdCtrls.pp
2. Go to function GroupBoxWindowProc
3. Add the following lines, just before WM_PAINT:

Code: Pascal  [Select][+][-]

1.  WM_KILLFOCUS, WM_SETFOCUS:
2.     Exit;
3.  

4. Rebuild IDE

The issue should be gone, hopefully without side effects.

Thank you. I will try it later today.

[tetrastes]

Yes, everything works fine. I did not find any anomalies so far.

I did. I applied this:

Code: Pascal  [Select][+][-]

1.   WM_KILLFOCUS, WM_SETFOCUS:
2.     begin
3.        Result := 0;
4.        Exit;
5.     end;    

(it seems more robust for me).

The OP issue went away, but try the following. Mouse click the empty space of GroupBox, press TAB, repeat if needed. Program stops responding to pressing TAB.
Remove WM_SETFOCUS:

Code: Pascal  [Select][+][-]

1.   WM_KILLFOCUS:
2.     begin
3.        Result := 0;
4.        Exit;
5.     end;    

it seems that program works fine now.

[GetMem]

@tetrastes
Very nicely done! I can confirm that your changes fix the TAB issue.

It seems that program works fine now.

Please run a few more test. I' m almost certain that we will find more issues. Changing something in LCL is always tricky.

@wp

Shouldn't we commit it to have a larger test base? If there is an issue with it we could remove the few lines again at any time...
And I think we should have a bugreport for it referring to this discussion to document why this is changed. This makes life much easier if somebody detects a regression some years later...

Not yet, @tetrastes already found a bug. I fully agree with the bugreport.

[tetrastes]

Please run a few more test. I' m almost certain that we will find more issues. Changing something in LCL is always tricky.

Unfortunately you are right.

it seems that program works fine now.

I was wrong. Without WM_SETFOCUS the OP issue is reproduced, but not with TaskBar:
1. Start test program
2. Start another program (Lazarus or Explore, maybe some others, but not all) which overlaps the test program.
3. Minimize that another program.
4. Mouse click the empty space of GroupBox of the test program.
5. Restore another program, then minimize it.
6. See the OP issue. 

EDIT: Maybe it is reproduced with clicking taskbar also, but I can't. But this method also shows the OP issue at test program with disabled DoubleBuffered, as KodeZwerg wrote, what I can't reproduce by clicking taskbar.

[GetMem]

@tetrastes
Please try with this:

Code: Pascal  [Select][+][-]

1.     WM_SETFOCUS:
2.       begin
3.         Result := WindowProc(Window, Msg, WParam, LParam);
4.         Info := GetWin32WindowInfo(Window);
5.         if Assigned(Info) and Info^.WinControl.IsEnabled then
6.           InvalidateRect(Info^.WinControl.Handle, nil, True);
7.         Exit;
8.       end;
9.     WM_KILLFOCUS:
10.       begin
11.         Result := 0;
12.         Exit;
13.       end;              

[tetrastes]

@GetMem
Seems it works.

[jamie]

For me it does not matter, it works either way here.

[dsiders]

@tetrastes
Please try with this:

Code: Pascal  [Select][+][-]

1.     WM_SETFOCUS:
2.       begin
3.         Result := WindowProc(Window, Msg, WParam, LParam);
4.         Info := GetWin32WindowInfo(Window);
5.         if Assigned(Info) and Info^.WinControl.IsEnabled then
6.           InvalidateRect(Info^.WinControl.Handle, nil, True);
7.         Exit;
8.       end;
9.     WM_KILLFOCUS:
10.       begin
11.         Result := 0;
12.         Exit;
13.       end;              

I tried this variant. It has the same problem with the button and combo-box disappearing. It just happens less frequently.

Tab navigation is alright though.

[jamie]

Try putting a InvalidateRect(Window, nil, false) within the WM_KILLFOCUS before exit.

 That wil force a refresh of the window.

 I don't see any wrong drawings over here anymore, must be something different between desktops and what you have on it.

 I will say however, I have seen other apps do this from time to time not fully painting their form going out of scope. The GUI in windows places these drawings at a low priority when things get busy.

[dsiders]

Try putting a InvalidateRect(Window, nil, false) within the WM_KILLFOCUS before exit.

 That wil force a refresh of the window.

 I don't see any wrong drawings over here anymore, must be something different between desktops and what you have on it.

 I will say however, I have seen other apps do this from time to time not fully painting their form going out of scope. The GUI in windows places these drawings at a low priority when things get busy.

I tried this too. Using the code:

Code: Bash  [Select][+][-]

1. diff --git a/lcl/interfaces/win32/win32wsstdctrls.pp b/lcl/interfaces/win32/win32wsstdctrls.pp
2. index a1dce61f60..8ba30d1577 100644
3. --- a/lcl/interfaces/win32/win32wsstdctrls.pp
4. +++ b/lcl/interfaces/win32/win32wsstdctrls.pp
5. @@ -583,6 +583,20 @@ begin
6.            InvalidateRect(Window, nil, True);
7.          Exit;
8.        end;
9. +    WM_SETFOCUS:
10. +      begin
11. +        Result := WindowProc(Window, Msg, WParam, LParam);
12. +        Info := GetWin32WindowInfo(Window);
13. +        if Assigned(Info) and Info^.WinControl.IsEnabled then
14. +          InvalidateRect(Info^.WinControl.Handle, nil, True);
15. +        Exit;
16. +      end;
17. +    WM_KILLFOCUS:
18. +      begin
19. +        Result := 0;
20. +        InvalidateRect(Window, nil, False);
21. +        Exit;
22. +      end;
23.      WM_PAINT:
24.        begin
25.          Result := WindowProc(Window, Msg, WParam, LParam);
26.  

It produces exactly the same results as the previous attempt. Controls still disappear but at a reduced frequency. Tab navigation is alright.