Bad repainting clip zone


#1

Well, I don’t know if it’s old or not, I’m using the latest Juce from Git (updated yesterday), and I got this whenever I move the old Jucer window other the new IntroJucer code editor:
[attachment=0]BadRepaintBug.jpg[/attachment]

To reproduce, you need to put IntroJucer on the bottom of the window stack, then add another window so it partially hide the IntoJucer (Acrobat reader / Explorer / Putty (whatever not always on top)), then move the old jucer’s window on top of this stack, the IntroJucer never update correctly.
It’s on Windows, of course.


#2

Hmm, thanks. Seems to only happen with a native title bar, I’ll get it fixed right away!


#3

Oh god, it’s because of this:
http://www.rawmaterialsoftware.com/viewtopic.php?f=3&t=6378

TheVinn, by fixing this I may break the change you suggested, so you might want to look at it again…


#4

[quote=“jules”]Oh god, it’s because of this:
http://www.rawmaterialsoftware.com/viewtopic.php?f=3&t=6378

TheVinn, by fixing this I may break the change you suggested, so you might want to look at it again…[/quote]

If I recall correctly there is an obscure bug with WM_PAINT where the area you are told to update is actually smaller than what you should update. I fixed it in an old project of mine by adding 1 to the right side of all the rectangles returned in the region (I think). The problem manifested itself when you drag an external window across your application window. It was likely fixed in Windows 7.

What platform is the original poster running on?

And also, the problem described in the post you quoted, never got fixed. I still maintain that windows with native title bars double-draw, and always seem to be one step “behind” the native window frame bounds during a resize operation. This problem does not happen with windows having Juce title bars, or other applications that compose their own DibSection offscreen, so that is pretty strong evidence of a bug.


#5

As you see in the screenshot, it’s Windows XP.
Anyway, if there really is a shortcut to squeeze NC_PAINT message processing, then for sure it’ll break, since NC_PAINT are also sent to trigger a full frame area repainting (yes, it’s a -relatively known- bug).
Please check this:
http://www.catch22.net/node/135


#6

Looking back at some old code this would be the equivalent in Juce

void Win32ComponentPeer::handlePaintMessage()
{
  //...
                                    // adjust for older versions of Windows
                                    const int cx = jmax (x, (int) rects->left - 1);
 // ...

Although looking at the OP’s screenshot, it seems it is a problem with the Y coordinate and this change can’t help it…


#7

Fixing it is no problem - it was caused by the change I made in response to the other thread, I’ll just revert that and it’s fine.