posted in the mail regarding the -noflicker option, as was written in the
documentation for the noflicker option, and as was noted in the changelog for
the noflicker option: IT BREAKS STUFF. If it didnt, it wouldnt be an
gratified to see that most of the stuff it's broken for you is nonstandard
Win32::GUI stuff (I mean, not part of Win32::GUI itself but add-ons). I'm
surprised that it breaks RichEdit, but not surprised that it breaks
-noflicker option should be considered an alpha fix, something that I'm working
on. You may be able to solve the problem you experience with disappearing
richedit controls by calling InvalidateRect on them, or adding PRF_OWNED to
the delivery of the WM_PRINT message in the CommonMsgLoops section of the
Incidentally, the reason it breaks Graphics is because Graphics is just a
DC, and thus is not "drawn" into a parent DC, but is stand-alone. WM_PRINT won't
capture the contents of other DCs, it simply tells a widget to draw itself into
the given DC, and one can't draw a DC into a DC.
as RichEdit goes, I'm guessing it simply doesnt support WM_PRINT at all. It will
require some looking into, and if all else fails making a compromise by
just making the RichEdit and Graphics controls flicker like they used
I've been testing with the latest source and I've
found various issues with the -noflicker option.
All the following controls resize correctly, but
the contents aren't visible until the user interacts with the control (say
moving a scroll bar). The contents of the control is windows
The following controls resize correctly, and the
contents are correct but the control still flickers.
* Graphic control
I've had a look through the source - but didn't
get anywhere. I can provide examples if needed.
Other than the issues, a great option. Nice