| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 487.1 | What do you do after XtManageChild? | TBD1::BURLEIGH | Dave, DECwindows Training | Tue Mar 28 1989 07:53 | 12 |
| I suspect that after call XtManageChild() on the caution box, your
program goes on to do other things. The modal operation of the caution
box is handled in XtAppMainLoop(), or XtMainLoop() if you use that
interface, not by the call to XtManageChild().
After calling XtManageChild() to make the caution box appear, your
code should return to the main loop, at which point the toolkit
event dispatcher will begin to filter out events that are not
related to the caution box.
Dave
|
| 487.2 | XSynchronize slowing you down maybe? | LATCP::MERSHON | Widget way should I go? | Tue Mar 28 1989 15:06 | 6 |
|
Did you by any chance make a call to XSynchronize somewhere in your
code??
P.S. Dave P. I got it right this time! :-)
|
| 487.3 | Yup - delayed wait | HGOVC::KENBERKUN | Klaatu Barato Nikto | Tue Mar 28 1989 23:10 | 44 |
| re .2 Nope, no XSynchronize
re .1 Yuppers - you got it.
The documentation says "When the style is Modal, it stops execution
of the applications and requires the user to provide input on how
to proceed."
I was taking this at its word.
In reality it does nothing until you to go back to the mainloop and then
forces the application to wait.
Now as I see it, that means I have to put the rest of my processing
code in the CautionBox callback routine. Is there a clean way to
stop in the middle of a procedure, go to the mainloop, then return
to the middle of the procedure?
I did move my stuff into the cautionbox callback and it works fine.
But it makes for ugly code.
Also, I was hoping to use the caution box for several different
cautions, just changing the label. Now with so much code in the
callback routine I'm more inclined to create a separate widget for
each caution. But this means writing a lot of UIL and extra callback
routines and doesn't seem very cost-effective to me.
But it would get pretty nasty to stick all this code for every
different eventuality into one callback (or even one for each button)
- even with a case statement.
Am I missing something obvious? (as I have several times already
:-))
A general question: Other programmers out there, are you reusing
your widgets with overrides, or do you set up a new widget for
everything?
Thanks for ideas and comments.
Ken B.
|
| 487.4 | | ULTRA::WRAY | John Wray, Secure Systems Development | Wed Mar 29 1989 11:34 | 23 |
| > Now as I see it, that means I have to put the rest of my processing
> code in the CautionBox callback routine. Is there a clean way to
> stop in the middle of a procedure, go to the mainloop, then return
> to the middle of the procedure?
No "clean" way yet. You can lobby for such a feature in notes 67
and 83 of the DECWINDOWS_PROGRAMMING conference. I agree that
currently the toolkit forces ugly programming style on the
application-writer; Hopefully more options will become available
to the programmer as the toolkit matures.
I currently use a single caution box for all my warning-type messages,
just changing the message text (using XT$SET_VALUES). I have to
use a global "pending-operation" variable which the OK callback
CASEs off to work out what I was doing before I decided to chat
with the user. The Cancel callback is pretty trivial - It's the
same non-code no matter what it is that I'm not doing :-)
Ugly, I agree, but I think it's better to do this than pay the penalty
of extra slow UIL fetches.
John
|
| 487.5 | Thanks | HGOVC::KENBERKUN | Klaatu Barato Nikto | Wed Mar 29 1989 21:02 | 9 |
| Thank you John. I just wanted to make sure I wasn't missing something.
Ugly or not, I love programming DECwindows. I always feel like
it's a lot of work while I'm doing it, but then when I run the code
I'm always impressed with how much I've accomplished relative to
the "old" way of doing things.
Ken B.
|