Oh, I should probably have noted that expose events are processed properly - forcing a repaint of an area, by dragging a window over it for instance, and IE will display that area properly. It's only on certain WM operations, like switching desktops, initial map, changing stacking order (for some reason this app forces the window to the bottom then back to the top while loading a page). So, I suppose I'm wondering if Z-Order bugs would interfere with the ExposeEvent->WM_PAINT dispatch system?
On Mon, 2003-05-19 at 12:12, Mike Hearn wrote:
Unfortunately it seems this "fix" did not fix my app at all, only the test case. Any other tips you might have on where the bug might be would be most appreciated.
thanks -mike
On Fri, 2003-05-16 at 18:08, Ulrich Czekalla wrote:
Hmmm that's not right. It makes me suspect even more that it's a z-order issue. Perhaps over the weekend I'll take a stab at it.
/Ulrich
On Fri, 2003-05-16 at 11:51, Mike Hearn wrote:
Hmmm, as a follow up, changing
if ((flags & DCX_CLIPCHILDREN) && (mode != ClipByChildren))
to
if (flags & DCX_CLIPCHILDREN)
in get_visible_region fixes it. I assume altering the assignment in GetDC would have the same effect.
I think this is what you were talking about earlier with Wine vs X11 clipping.... it seems in this case leaving it up to X doesn't work. I don't understand enough about this area to submit a proper patch though, so I just thought I'd let you know what change fixed the problem.
thanks -mike