Hi,
Unfortunately I never received the original email from the list - spam filters
are at work stopping me receiving some of the posts. I've rejoined under a
different email address.
My app is fairly complex, with hundreds of controls and 23 windows. The fact
that -noflicker works so well is impressive.
The symptoms of the RichEdit control are similar to Grid in that the contents
aren't visible until the control is changed (say by moving the scroll bar). On
a resize you can *sometimes* (difficult to reproduce on a consistent basis) see
the flash of the original contents of the RichEdit - all you are left with is
an empty grey control. By the looks of things the RichEdit draws itself in two
phases, the first it greys out the contents, and paints the bounding box, and
in the second it paints the contents. Does this make any sense?
I'd be happy to supply examples. I'll try the suggestions you made.
Cheers,
jez.
----- Original Message -----
From: Stephen Pick
To: Jez White ; guihackers
Sent: Wednesday, December 17, 2003 10:49 AM
Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Yes yes yes.
As was 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 option.
I'm 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 Graphics.
The -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 GUI_MessageLoops.cpp file.
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 far 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 to.
Steve
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 16 December 2003 14:11
To: guihackers
Subject: [perl-win32-gui-hackers] -noflicker Feedback/bugs
All,
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 grey.
* Win32::GUI::Grid
* Win32::GUI::Scintilla
* RichEdit
The following controls resize correctly, and the contents are correct but
the control still flickers.
* Win32::GUI::AxWindow
* 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 work.
Cheers,
jez.
