Ok. Some more info.
I'm scaling the control in the _Resize handler of the window. I've just tried
InvalidateRect and had some interesting results. If the InvalidateRect is used
in the Resize handler nothing happens but if InvalidateRect is included an
another event, then the control is redrawn correctly. As for the grey, same
grey as the window background (same for the grid control).
The Grid control is by Laurent, and is in C - from memory there might have been
a board associated with the control too.
23 windows and just under 500 controls - and still growing:)
If you want me to try anything else, drop me an email.
Cheers,
jez.
----- Original Message -----
From: Stephen Pick
To: Jez White ; guihackers
Sent: Wednesday, December 17, 2003 12:13 PM
Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Aha. I know what this is.
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.
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.
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.
23 windows?!
Steve
-----Original Message-----
From: Jez White [mailto:[EMAIL PROTECTED]
Sent: 17 December 2003 11:53
To: Stephen Pick; guihackers
Subject: Re: [perl-win32-gui-hackers] -noflicker Feedback/bugs
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.
