Clipping regions on windows and Expose Xevents issue

[Ann & Jason Edmeades]

Thanks Alexandre,

(BTW This createwindow / movewindow / draw to window is all occurring in
LBUTTONDOWN processing)

>> 1. MoveWindow doesn't update the DCEx clip_region region, and hence when
the
>> visible region changes, it is merged with the clip region and since there
is
>> no overlap the visible region is empty so all subsequent processing ends.
>>
>> Q: Whats the best way to handle that - I was tempted to reset the
>> clip_region to the visible_region (as MSDN sort of implies - you cant
really
>> query them so tests don't help much here) in a movewindow call

>You can query the visible region, so with well-chosen dimensions and
>clip region it shouldn't be too hard to write test cases. Make sure you
>test both GetDCEx with an explicit clip region and BeginPaint, the
>behavior is probably different

The difficulty here is the inability to directly query the concealed (within
the struct DCE) clip_rgn not the visible region. For example, GetClipRgn
returns dc->hClipRgn, whereas the dce clip_rgn is internal to user32
painting.c. The only call I can see replaces the region with GetDCEx? 

What kind of test did you have in mind - The only idea I had was something
like CreateWindow at 100,100, begin paint, MoveWindow to 50,50, FillRect
into red, endpaint, then read it back to see if it really is read?


>> Q: This is getting way outside my understanding of X events, but
shouldn't
>> the Expose event for the child (popup) window be processed before
returning
>> from CreateWindow with style WS_VISIBLE?

>The way we hack around the asynchronous events is by checking for expose
>events in UpdateWindow, but of course if the app doesn't even use that
>it won't help. And on a slow connection the expose events will always
>arrive too late anyway. We'd need to explicitly wait for the event, but
>that would hurt badly on slow connections.

The app is processing in a WM_LBUTTONDOWN, and just creates a window and
draws to it immediately, and the windows message loop wont redraw it. Is
there any workaround for this or is it going to be an impossibility to get
it working? (I wondered, for example, if we can do anything about ignoring
the first expose if the window was created as visible, or removing the
rdw_erase if the window had explicitly painted itself before the first
event)?

Jason