burzio@mmlai.UUCP (Tony Burzio) (08/03/90)
Does anyone have a short example of how to register more than one callback for a single event? What I am heading for is this: when a user presses a button I want a message dialog to completely pop up, then several minutes of processing to take place. With a single callback, the dialog border from mwm apears, but none of the internal widgets appear until the complete callback is finished. Does anyone have any advice? ********************************************************************* Tony Burzio * I see, I see... Martin Marietta Labs * mmlai!burzio@uunet.uu.net * A desert vacation is in your future... *********************************************************************
devin@pippin.Colorado.EDU (Yampalimardilor) (08/04/90)
In article <9008032150.AA19613@alphalpha.com>, nazgul@alphalpha.com (Kee Hinckley) writes: |> > Does anyone have a short example of how to register |> > more than one callback for a single event? What I |> I'm not sure this is what you want. All you have to do for |> that is repeatedly do XtAddCallbacks, but that isn't going |> to fix your problem. |> > am heading for is this: when a user presses a button |> > I want a message dialog to completely pop up, then |> > several minutes of processing to take place. With a |> > single callback, the dialog border from mwm apears, but |> > none of the internal widgets appear until the complete |> > callback is finished. Does anyone have any advice? |> The problem is that you are running off and doing some processing |> before the widget has finished getting all the display events. |> The only solution that I can think of is waiting until the dialog |> box gets an expose event and then executing your code (perhaps calling |> XmUpdateDisplay first in case there are more expose events queued? I'm |> not sure). I have not yet, however, had the time to explore how to |> do this. Does anyone know? |> -kee Try writing a timer callback that does your long processing job and then right before you want to do that do: XtAppAddTimeOut(appcontext,0,timerCB,NULL); This adds the time out at the end of the event queue (because it goes off immediately) and so forces the processing of everything in front of it. (i.e. expose events...) -Devin |> |> Alphalpha Software, Inc. | motif-request@alphalpha.com |> nazgul@alphalpha.com |----------------------------------- |> 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 |> |> I'm not sure which upsets me more; that people are so unwilling to accept |> responsibility for their own actions, or that they are so eager to regulate |> everyone else's. |> |> ------- *********************************************************************** * Yampalimardilor * a.k.a Devin Hooker (RP90) DoD # 0034 * * Mage School, Glantri * University of Colorado-Boulder * * (Master of Movement) * (Undergrad Student) * ***********************************************************************
carl@quad1.quad.com (Carl Priddy) (08/07/90)
In article <7@gauss.mmlai.UUCP>, burzio@mmlai.UUCP (Tony Burzio) writes: > Does anyone have a short example of how to register > more than one callback for a single event? Well, I am not sure if your problems are caused by the lack of multiple callbacks, but as I found out by accident just recently, the use of XtAddCallback() does just what the name implies: it ADDs a callback. That is, if you enter a loop which calls XtAddCallback() 'n' times with the same widget and arguments, when the event occurs it will invoke that callback 'n' times. -- example -- Widget wl; VOID cbrtn(); int i; .. .. /* * assume that wl is a pushbutton */ for (i = 0; i < 5; i++) XtAddCallback(wl,XmNactivateCallback, cbrtn,i); ... Now, when the button is activated, there will be 5 calls to cbrtn(), with then numbers 0-4 passed as client data. carl.