| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1422.1 | The Session Manager does it... | CADSE::STRAIGHT | Rob Straight | Mon Sep 18 1989 12:35 | 27 |
| The software being written is similar in function to the Session
Manager. It has a menu bar that is always active (which implies
XTMainLoop has been called), and it is also able to receive
asynchronous messages from a number of applications. Can anyone
shed some light on how this works?
This is what's been tried:
-create a mailbox to receive messages
-issue a QIO to read the mailbox. An AST routine will be called when
the read is complete
-setup the menu (consisting of "start" and "quit"), and call XTMainLoop
-when a message arrives in the mailbox, the AST routine gets called.
It displays the message in the list box, and then issues another
QIO to read the next message (using the same AST routine).
Currently this is implemented, but it access violates in the AST
routine, probably at the point where the DwtListBoxAddItem routine
is called (the debugger gets lost, unfortunatly).
Does anyone know if this method of using AST's to get out of the
XTMainLoop should work? Or any alternative suggestions to solving
the problem? Maybe a pointer to the owner (or source) of the
Session Manager?
Thanks!!
|
| 1422.2 | | AITG::DERAMO | Daniel V. {AITG,ZFC}:: D'Eramo | Mon Sep 18 1989 16:51 | 8 |
| >> Currently this is implemented, but it access violates in the AST
>> routine, probably at the point where the DwtListBoxAddItem routine
>> is called (the debugger gets lost, unfortunatly).
You can't call toolkit routines at AST level.
Dan
|
| 1422.3 | Replace XtMainLoop? | CADSE::STRAIGHT | Rob Straight | Mon Sep 18 1989 17:45 | 16 |
| Ok, how about if I replace the XtMainLoop call with the next and
dispatch event calls? There's also an appl_pending call that could
be used to keep the whole thing from blocking while waiting for input?
Something like:
if XtApplPending(application_context) > 0
then
XtApplNextEvent(application_context,event)
XtDispatchEvent(event)
endif
Does this seem workable?
Rob
|
| 1422.4 | ...more... | GSRC::WEST | Varibles don't, Constants aren't | Mon Sep 18 1989 18:05 | 14 |
|
If you are using XtInitialize then the XtApp* calls are not necessary. Just
use XtPending, XtNextEvent and XtDispatchEvent.
After the XtDispatchEvent call you could do your own processing...this however
is considered bad programming. If you were to do it this way it has been said
that you must process events at least every 1/4 second.
The recommended way is to use work procedures. There are numerous notes on
this subject in this and other related conferences.
-=> Jim <=-
|
| 1422.5 | add input for async io events | CSC32::B_WACKER | | Mon Sep 18 1989 18:13 | 3 |
| Also, instead of AST, use ADD INPUT to generate a callback to handle
the io.
|
| 1422.6 | | PSW::WINALSKI | Careful with that VAX, Eugene | Mon Sep 18 1989 19:22 | 12 |
| You can use ASTs to receive the asynchronous events, post them to data
structures where the main, synchronous part of your application can find them,
and then use XtPending() and XtNextEvent() to do X event dispatching,
interspersed with your own processing. The only catch is that you must check
for and dispatch X events on a timely basis (the 1/4 second rule). VMS
Mandelbrot is an example of an application that does this. It also illustrates
the use of client messages sent from AST routines to "unstick" the application
when it's waiting in XtNextEvent(). Look at modules M_DISPLAY.C AND WIDGETS.C
in TLE::ULNK$:[WINALSKI.MANDELBROT.V41_SOURCE].
--PSW
|