Hi, Ecsa
I tried your test project on win 7/64 pro, Lazarus 2.2.0, FPC 3.2.2 for both targets - win64 and win32 - it seems there is no problem. Nothing strange (as you described) happened to me.
Your months of an unsuccesful fight sound alarming.
My suggestions - check Lazarus installations, viruses, hardware. May be it is better to use 64 bit installation of Lazarus with support of 32 bit target? (Needed downloading and installing cross-compiller lazarus-2.2.4-fpc-3.2.2-cross-i386-win32-win64.exe).
My current only work-around, quick and dirty:
Still, I would like to understand why I am not seeing this. Are you using anchordocking?
Still, I would like to understand why I am not seeing this. Are you using anchordocking?I tried with a full installation of my Lazarus, lots of Components from OPM added also AnchorDocking. How can that have an impact for running an compiled executable?
Still, I would like to understand why I am not seeing this. Are you using anchordocking?
The issue is reproduced at my Win10 Laz 2.2.4 fpc 3.2.2.That I also tried, keep doing activate/deactivate the window and you see the error again. At least there is another person that can confirm that strange behaviour.
I have discovered that it is linked with DoubleBuffered somehow, maybe because TListView and TProgressBar have not DoubleBuffered property.
I have set GroupBox1 DoubleBuffered property to False, and the issue goes away.
Buena suerte y de nada // Good luck and you're welcomeI just applied it to another form from another project and the same problem doesn't work, I'm going to remove the groupbox so I don't see that bug, anyway, thank you very much for your support. :'(
The issue is reproduced at my Win10 Laz 2.2.4 fpc 3.2.2.
I have discovered that it is linked with DoubleBuffered somehow, maybe because TListView and TProgressBar have not DoubleBuffered property.
I have set GroupBox1 DoubleBuffered property to False, and the issue goes away.
I am sorry that my fix did not worked on your other projects :'( I tried best to help :-[Buena suerte y de nada // Good luck and you're welcomeI just applied it to another form from another project and the same problem doesn't work, I'm going to remove the groupbox so I don't see that bug, anyway, thank you very much for your support. :'(
You can test that while debugging by testing the parent control. If that is the form and not the panel... then you have the issue as I described above.This is not the case. The parent of all controls is GroupBox1, what you can easily see in Object Inspector.
It is likely that, that the control that you assume to contain other controls did not have focus at the time you added the other controls.
Example: when you want to put controls on a panel, make sure the panel has focus (the squares around the corners and the middles) before you add the controls visually. Otherwise the owner becomes the form itself, and not the panel and that may hide the controls. (same goes for Delphi, but Delphi behaves a bit better than Lazarus that can mix-up order quite easily: meaning last added control does not have the same z-order as you would expect (LIFO), so in Delphi it mostly "looks" OK, but it isn't either: same programmer mistake).
This is a "pitfall" forscreendrawerssorry, beginners, but not usually for programmers.
You can test that while debugging by testing the parent control. If that is the form and not the panel... then you have the issue as I described above.
Application.ProcessMessages in the OnDeactivate event?Sadly not.
I've run and tested, strange thing is, when I build on my own, all works like it should,Same here.
importing and running your demo shows me same behaviour.I don't understand this part. Importing what and running what ?... his zip file does not contain an executable (at least not the one I downloaded.) How did you run "his demo" (presuming you mean "his executable" an executable _he_, not you, created ?.) What am I missing ?
Could those who see this issue tell us the exact operating system they are using? Couldn't it be that this is due to one of the many bugs introduced by Microsoft after Win 7 and which are now gradually removed?
Mine is Win-11 Home (64 bit) Version 22H2, Build 22621.1105, and I also have a Win-7 Pro Service Pack 1 (32 bit) on a VM. None of them shows the issue.
Could those who see this issue tell us the exact operating system they are using? Couldn't it be that this is due to one of the many bugs introduced by Microsoft after Win 7 and which are now gradually removed?I can reproduce the issue with every Lazarus/FPC version I have, both on win10 and win11. The issue is more serious then I thought: TGroupBox, TRadioGroup, TCheckBox are all affected. It's related to the DoubleBuffered property, as mentioned in one of the previous posts. If I set DoubleBuffered to False the issue is gone.
Mine is Win-11 Home (64 bit) Version 22H2, Build 22621.1105, and I also have a Win-7 Pro Service Pack 1 (32 bit) on a VM. None of them shows the issue.
5. Click ten times or so inside the TGroupBox"inside the TGroupBox" - does this mean: "on the controls" or "somewhere, but not on the controls"?
Somewhere, but not on the controls.5. Click ten times or so inside the TGroupBox"inside the TGroupBox" - does this mean: "on the controls" or "somewhere, but not on the controls"?
6. Click a few times the taskbar. It will only work if you click the taskbar, the empty part of the taskbar
OK, good to know. Thanks!6. Click a few times the taskbar. It will only work if you click the taskbar, the empty part of the taskbar
If I create a shortcut to a program on the desktop and launch it from the shortcut, this behavior is also displayed when clicking on an empty space on the desktop.
If I set DoubleBuffered to False the issue is gone.Sadly not. Just de-/activate window more often and you get same issue.
If I set DoubleBuffered to False the issue is gone.Sadly not. Just de-/activate window more often and you get same issue.
I turned DoubleBuffer to False for everything = issue is there.
(...With my fix it is gone...)
when the taskbar is clicked[...]It's not only the taskbar. It happens also when I click into an IDE form rather than the taskbar.
Sure, it's not about the taskbar. With my demo project, I only wanted to prove that is a repaint issue.when the taskbar is clicked[...]It's not only the taskbar. It happens also when I click into an IDE form rather than the taskbar.
Can someone drop a TComboBox on the form using csSIMPLE style and stretch it out vertically and add some items.The issue is visible with or without a TComboBox. Style, align does not matter.
It seems if though if I simply block those messages from being processed it works fine?Apparently that solves the issue, I don't see any side effects either. However modifying LCL is always tricky, needs thorough testing before it can be applied in main.
I also noticed the TAB operation seems to be funky, but it does not matter either way you alter the code, tabbing seems to be another abnormally.
So doing this instead of InvalidateRect...
WM_KILLFOCUS,WM_SETFOCUS: Exit;
DO that in the same area instead and try that, it appears everything is working!?
I have not found any side effects doing this so this I will finalize instead. It seems to work.
It seems if though if I simply block those messages from being processed it works fine?Apparently that solves the issue, I don't see any side effects either. However modifying LCL is always tricky, needs thorough testing before it can be applied in main.
I also noticed the TAB operation seems to be funky, but it does not matter either way you alter the code, tabbing seems to be another abnormally.
So doing this instead of InvalidateRect...
WM_KILLFOCUS,WM_SETFOCUS: Exit;
DO that in the same area instead and try that, it appears everything is working!?
I have not found any side effects doing this so this I will finalize instead. It seems to work.
@all
Please test @jamie's changes.
It seems if though if I simply block those messages from being processed it works fine?Only difference - if WindowProc is called and what result it returns.
I also noticed the TAB operation seems to be funky, but it does not matter either way you alter the code, tabbing seems to be another abnormally.
So doing this instead of InvalidateRect...
WM_KILLFOCUS,WM_SETFOCUS: Exit;
DO that in the same area instead and try that, it appears everything is working!?
I have not found any side effects doing this so this I will finalize instead. It seems to work.
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
The issue should be gone, hopefully without side effects.Where can I find contents of GroupBox's WindowProc? I guess, DefWindowProc should be called for these messages. It is possible, that WindowProc overrides this behavior. Even if it just returns wrong result. Remember, that in most cases 0 result means processing message by application.
1. Open: $(LazarusDir)\lcl\interfaces\win32\Win32WSStdCtrls.pp
2. Go to function GroupBoxWindowProc
3. Add the following lines, just before WM_PAINT:4. Rebuild IDE
The issue should be gone, hopefully without side effects.
Where can I find contents of GroupBox's WindowProc?$(LazarusDir)\lcl\interfaces\win32\Win32WSStdCtrls.pp
I guess, DefWindowProc should be called for these messages. It is possible, that WindowProc overrides this behavior. Even if it just returns wrong result. Remember, that in most cases 0 result means processing message by application.@tetrastes
I am not sure in that also, as Mr.Madguy. GroupBoxWindowProc must return something. What does it return in this case?
$(LazarusDir)\lcl\interfaces\win32\Win32WSStdCtrls.ppNo, GroupBoxWindowProc calls Result := WindowProc at the end. What is called? Things are hard to track in WS classes.
1. Menu -> Tools -> Configure "Build Lazarus" ..$(LazarusDir)\lcl\interfaces\win32\Win32WSStdCtrls.ppNo, GroupBoxWindowProc calls Result := WindowProc at the end. What is called? Things are hard to track in WS classes.
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.Yes, everything works fine. I did not find any anomalies so far.
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...
@dsidersQuoteI 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:4. Rebuild IDE
The issue should be gone, hopefully without side effects.
Yes, everything works fine. I did not find any anomalies so far.
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.
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...Not yet, @tetrastes already found a bug. I fully agree with the bugreport.
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...
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:
@tetrastes
Please try with this:
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
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?
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
This is my last attempt:
@Mr.Madguy
Did you applied the patch?
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.Thanks again. I will wait a few more days just in case.
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.
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.