Controls inside the form disappear in execution.

[balazsszekely]

@dsiders

Thank you! What are the exact steps to make the controls disappear? I cannot reproduce the issue here, no matter how hard I try. Do you click on the taskbar and back to the application or something else?

[dsiders]

@dsiders

Thank you! What are the exact steps to make the controls disappear? I cannot reproduce the issue here, no matter how hard I try. Do you click on the taskbar and back to the application or something else?

 I used the process you outlined:

Click on an unused area in the group box about 10 or 12 times.
Click on an unused area in the task bar.
Rinse and repeat until the error happens.

The clicks (on the group box) had to be pretty close together... and it took 8 or 9 cycles to get the error to occur.

[Mr.Madguy]

For me it's enough to:
1) Create new project
2) Add group box to form
3) Add button to group box
4) Run project
5) Click group box
6) Click task bar
7) Button disappears

Sometimes problem doesn't happen - button just flashes. But in most cases it happens.

[balazsszekely]

@dsiders
This is my last attempt:

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

1.     WM_SETFOCUS, WM_KILLFOCUS:
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;

@Mr.Madguy
Did you applied the patch?

[Mr.Madguy]

Did you applied the patch?

No. Because I think, that something wrong happens here. Other problems should be checked before adding such crutch. First of all, both form and group box have WS_CLIPCHILDREN and WS_CLIPSIBLINGS. And while such problem was understandable back in WinXP era, we have had composite window manager since Vista. Such problems just shouldn't happen in a first place.

[dsiders]

@dsiders
This is my last attempt:

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

1.     WM_SETFOCUS, WM_KILLFOCUS:
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;

@Mr.Madguy
Did you applied the patch?

I tested with the code:

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

1. diff --git a/lcl/interfaces/win32/win32wsstdctrls.pp b/lcl/interfaces/win32/win32wsstdctrls.pp
2. index a1dce61f60..4f0df31e84 100644
3. --- a/lcl/interfaces/win32/win32wsstdctrls.pp
4. +++ b/lcl/interfaces/win32/win32wsstdctrls.pp
5. @@ -583,6 +583,14 @@ begin
6.            InvalidateRect(Window, nil, True);
7.          Exit;
8.        end;
9. +    WM_SETFOCUS, WM_KILLFOCUS:
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_PAINT:
18.        begin
19.          Result := WindowProc(Window, Msg, WParam, LParam);
20.  

I've been clicking like a mad man and cannot make this variant reproduce the issue. Tab navigation works as expected. And I see no adverse affects of any kind.

Now, I never saw the issue to begin with when using the application like a normal human being. And this version seems to pass the ADD test.

Time for a cold one.

[balazsszekely]

@dsiders

I've been clicking like a mad man and cannot make this variant reproduce the issue. Tab navigation works as expected. And I see no adverse affects of any kind.

Now, I never saw the issue to begin with when using the application like a normal human being. And this version seems to pass the ADD test.

Time for a cold one.

Thanks again. I will wait a few more days just in case.


@Mr.Madguy

No. Because I think, that something wrong happens here. Other problems should be checked before adding such crutch. First of all, both form and group box have WS_CLIPCHILDREN and WS_CLIPSIBLINGS. And while such problem was understandable back in WinXP era, we have had composite window manager since Vista. Such problems just shouldn't happen in a first place.

Please do check for other problems, maybe you can come up with a better idea.