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

[Jez W. <je...@je...>]

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 Pick=20
  To: Jez White ; guihackers=20
  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: 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

    I've been testing with the latest source and I've found various =
issues with the -noflicker option.=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.

    * Win32::GUI::Grid=20
    * Win32::GUI::Scintilla=20
    * 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.