At 01:49 PM 8/24/99 +0900, Stephen J. Turnbull wrote:
>>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> In fact I'm still pretty convinced that the expose events
Andy> are for the widget being *unmapped* rather than mapped.
In X11, an unmapped window can't receive events at all because it's
invisible. If all of the descendents of the subwindow/glyph are
mapped first, then the subwindow/glyph is mapped, it cannot step on
its own toes (unless that causes its children to reconfigure
Its not the subwindow receiving the expose event - its the XEmacs frame for
the exposed area which causes redisplay to redisplay and so on....
themselves). I guess it's possible that since tabs are normally
used
in dialog boxes, the programmer got away with an implicit assumption
that the tab control widget would always be on top, and wouldn't have
to deal much with Expose events.
>> One (naive) way to help accomplish both of these goals would be
>> to have the subwindow itself be a "shell" window
I'm becoming rapidly convinced this is the way to go. I got a < 1 sec
This won't affect flashing though.
flash where I saw the tabs completely discombobulated, in no
particular order, not in a row (maybe about three rows?) Can't
reproduce, of course :-(
I've told ed about the tab build problems, hopefully he will be able to
figure something out.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd