| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
If I manage a widget in a callback-routine the widget gets only
visible after the 'ret' of the callback. WHY?
Why is it not visible after the XtManageChild-routine?
I also tested this problem with XtMapWidget.. and had the same
result.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 617.1 | X is asynchronous | SDSVAX::SWEENEY | Wall Street is my beat | Tue Apr 18 1989 10:53 | 21 |
X, in general, and the X Toolkit, of which DECwindows is a layer on top,
is heavily asynchronous, that is to say the state of the client and the
state of the server (or what is currently displayed) is not
synchronized by the intent of the X designers.
This design facilitates non-blocking client applications, except at the
explicit point where the client has no output and no computing to
perform and then the application waits for an X event.
To get output displayed immediately one has to flush the output buffer
(XFlush is the routine). But you shouldn't have to do that.
Your program should not need to count on XtManageChild mapping the
window in the middle of the callback routine. As far as an
applications is concerned (or ought to be concerned), all output
..eventually.. gets displayed.
Could you explain why you need synchronization of XtManageChild in your
callback routine?
| |||||
| 617.2 | During debugging it's nice to see cause and effect | HANNAH::MESSENGER | Bob Messenger | Wed Apr 19 1989 00:31 | 7 |
Re: .0 Elaborating on .1, during debugging it's often useful to make all your X calls synchronous by calling XSynchronize. This is a *big* performance hit, though. -- Bob | |||||