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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Win32::GUI::Grid is based on MFCGrid.=20
WM_PRINTCLIENT isn't handle by default with MFC.

I made change for support it in next release.
Grid work nice now with -noflicker option enabled.

I need to see for Scintilla control.

Laurent.

  ----- Original Message -----=20
  From: Jez White=20
  To: Stephen Pick ; guihackers=20
  Sent: Wednesday, December 17, 2003 1:39 PM
  Subject: Re: [perl-win32-gui-hackers] -noflicker Feedback/bugs

  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. =20
    ----- Original Message -----=20
    From: Stephen Pick=20
    To: Jez White ; guihackers=20
    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: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 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.