> If state is added via some global, and I set up a bunch of
> flags to indicate what state it is in, it would be doable. However the
> code would go from logical and simple to obscure and complex. ...
No need for a global. You can pass a pointer to your state structure
as the void * parameter. With a state structure, you just instantiate
a copy of the structure for each transaction.
> No, the app does not need to do anything else, and in fact
> specifically should not be doing anything else. If I was to rewrite it
> to use add_io_callback() the very first thing the callbacks from the
> user interface buttons would do is totally disable all input and
> response to user interaction until the low-level interaction was complete.
What if you want to add an option to abort the transfer? This would
require some interaction with the GUI. Doing what you're proposing
would probably necessitate major changes.
I'm not going to argue the point any further, however.
> I tried looking up using XFlush(), but that wants a display
> arg passed. Does the xforms library provide an instance or a pointer
> to a display struct already filled in with the current display? ...
fl_get_display() returns the current display. The Friendly Manual
will tell all.
... And is
> the fact the changes I am making via the fl_set_object_label() calls
> aren't shopwing up definately due to the lower-level Xlib layer and
> not something in the Xforms layer?
As far as I'm aware, yes.
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/