>From "Orn E. Hansen" <oe.hansen@oehansen.pp.se> :
> ... The
> graphical user interface, or GUI, is functionally the main loop of every
> program. However, I have a case where I would like this to be turned
> around. A program, where the main loop is a communications between two
> or more computers, that rarely needs a human interaction. ...
> [...]
> I therefore ask, isn't it possible to make the event interaction
> between the program and the library an Interrupt driven routine? ...
I think doing this would break the X programming model.
If your program is truly interrupt driven and these interrupts are
presented to your program in the form of standard Unix signals, then
you can use the signal handling capability of XForms to process them.
There are also asynchronous I/O handling facilities in XForms which
may be useful.
Other alternatives are to use fl_check_forms() in your own main loop
or to simply pop the form you need to interact with the user when it's
necessary and only drop into fl_do_forms() when the form is present.
There's no hard and fast rule that dictates that a form must always be
present. I've done this in an application which only needs to pop
warnings and brief operator interactions and it works fine.
A caveat here -- if you're actually processing during your own signal
(interrupt) handler, you have to be careful not to disarrange the
state of X. For instance, as we've discussed on this list before, X
is not reentrant -- meaning that if your signal interrupts something
happening down in the bowels of X, you're probably eventually going to
lose.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/