RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs

[Stephen P. <Ste...@uc...>]

Aha. I know what this is.
=20
A few Windows controls draw themselves (or parts of themselves) outside =
the WM_PAINT DefWndProc. Most should draw in WM_PAINT, but a very few =
(like RichEdits, if I remember correctly) draw when some other messages =
are posted, such as "i have been modified" messages etc. In other words, =
they handle their own redrawing by sending themselves messages =
internally. I'd have to spend some time on MSDN checking out where =
RichEdits actually draw themselves, but I don't have time to dig into =
that right at this minute.
=20
There will obviously need to be a few special cases for controls that =
don't work quite as expected. Are you resizing the richedit control with =
the window (scaling it in the window's xxx_Resize handler), or is it =
just the window on it's own that you are resizing? What happens if you =
InvalidateRect on the richedit control whenever the window is being =
resized? You say you're left with an empty grey control. Is the grey a =
different grey to the window background? If you're left with a dark grey =
box that at least tells me that SOMETHING is being done on WM_PRINT, =
probably - as you said - just the groundwork for subsequent drawing of =
the control contents.
=20
I believe the grid control you mentioned is one of Laurent's modules and =
it uses some third party opensource grid control code written in C, I =
think he links to it on his site so I can have a look through that code =
and find out just why that particular control isn't drawing right. One =
hopes that WM_PRINT is implemented there.
=20
23 windows?!
=20
Steve

-----Original Message-----
From: Jez White [mailto:je...@je...]
Sent: 17 December 2003 11:53
To: Stephen Pick; guihackers
Subject: Re: [perl-win32-gui-hackers] -noflicker Feedback/bugs


Hi,=20

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.=20

My app is fairly complex, with hundreds of controls and 23 windows. The =
fact that -noflicker works so well is impressive.=20

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?=20

I'd be happy to supply examples. I'll try the suggestions you made.=20

Cheers,=20

jez.=20

----- Original Message -----=20
From: Stephen  <mailto:Ste...@uc...> Pick=20
To: Jez White <mailto:je...@je...>  ; guihackers =
<mailto:per...@li...> =20
Sent: Wednesday, December 17, 2003 10:49 AM
Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs

Yes yes yes.
=20
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.
=20
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.
=20
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.
=20
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.
=20
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.
=20
Steve

-----Original Message-----
From: per...@li... =
[mailto:per...@li...]On Behalf Of =
Jez White
Sent: 16 December 2003 14:11
To: guihackers
Subject: [perl-win32-gui-hackers] -noflicker Feedback/bugs


All,=20
=20
I've been testing with the latest source and I've found various issues =
with the -noflicker option.=20
=20
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.
=20
* Win32::GUI::Grid=20
* Win32::GUI::Scintilla=20
* RichEdit
=20
The following controls resize correctly, and the contents are correct =
but the control still flickers.
=20
* Win32::GUI::AxWindow
* Graphic control
=20
I've had a look through the source - but didn't get anywhere. I can =
provide examples if needed.
=20
Other than the issues, a great option. Nice work.
=20
Cheers,
=20
jez.
=20