From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
Newsgroups: comp.windows.x.motif
Subject: Re: XmMessageBoxProblem
Date: 12 Nov 92 18:00:16 GMT
Distribution: inet
Organization: Oceanroutes Canada Inc.

Andrew Edgar <clhawth@ccu.umanitoba.ca> writes:
> 
>       I am trying to pop up a working message while my program does
> some large processing.  Within a callback I popup the warning box
> and then start the processing.  The problem is that the label and the
> buttons on the message box do not appear until after the callback from
> which I popped the message box is finished.  I have tried using 
> XmUpdateDisplay and XFlush to get the requests done before I make the call
> to the time consuming procedure.   Any help in this problem would be much 
> appreciated.
> 
You may find the following of some help, the first is from the 
comp.windows.x.motif group, the second from comp.windows.x

Let me know if you need any further help on this topic. ... Terry

======================== included message number one =====================

Mark McWiggins <markmc@sierra.com> writes:
> 
> I have a menu button attached to a callback that takes a minute or so to
> run, building a complicated palette. I'd like to first bring up an
> XmWorkingDialog to say 'not dead, just working.' Of course in this callback
> X doesn't get control to be able to update the display, so I thought I'd
> have to do some special trick. But none so far have worked! The dialog shell
> comes up, but the MessageBox inside doesn't.  I've tried:
> 
> (1) Calling XmUpdateDisplay right after managing the dialog;
> 
> (2) Setting up the callback to just create & manage the WorkingDialog and
> return, and having the real work done from a call via an XmWorkProc.
> 
> Number (2) is of course quite a kludge, but I certainly expected it to
> work. I didn't think the WorkProc would get called until X had taken care
> of everything else in its queue, which I'd expected to have included managing
> the MessageBox.
> Obviously I've missed something here. But what?
> 
The problem is that you are responsible for time slicing your work
procedure yourself (this is a feature! who can do it better?).
Your XtWorkProc should return with False after every few (~100)
milliseconds and remember what it was doing, expecting to be called
again shortly.  Return with True when you are all through.

The only other way is to fork to a non-X process to do your work,
but in your case you need to *do* X work, so that is out.

It might seem at first that all this is too much for such a simple
thing, but remember X is a *server*; if you keep control in a
function for a long time without giving it back control, it won't
interfere - that's your perogative. 

... Terry

======================== included message number two =====================

From: converse@expo.lcs.mit.edu (Donna Converse)

[some stuff deleted]

In most R4 Xt libraries, returning True from a work procedure will cause
a memory leak.  To work around the bug, the work procedure can be removed
from the queue of work procedures by calling XtRemoveWorkProc, which will
not leak; however please note that it is unacceptable practice to make
this call from the same work procedure which is being removed.  

> Is there any fix for this leak. (I have not tried in X11R5)

This bug is not present in the R5 Xt library. 

[fix for R4 source deleted]

============================== end of included messahes ====================
Newsgroups: comp.windows.x.motif