>>>>> "Dikoma" == Dikoma C Shungu <shungu@ultranmr.cpmc.columbia.edu> writes:
Dikoma> Nothing to add here, except that I fully & *strongly*
Dikoma> agree with Steve's [spl] last point here. I would opt for
Dikoma> asynchronous I/O. I will elaborate if the poster wants me
Dikoma> to, but it is cleaner (just dealt with something like
Dikoma> today!)
It's not cleaner when you want to avoid multiple threads, and
you have lots of bidirectional I/O going on that must be handled in
sequence by the nature of what is being done. To allow this to
function via an I/O callback would require adding some state, wrapping
all calls to disable all user input during the time it was busy, and
adding an incredibly complex parser to try and figure out exactly what
this incoming data related to, all in millisec timing. It could be
done by spawning a whole subtask which sat there and did all the work,
and then I could simply lock the UI while it was busy, but the whole
point of what I am doing is to try and eleminate having a seperate UI
and back-end.
Like I said, the default behavior is exactly what I want, with
the exception that I would like to be able to update a status display
in the xforms controlled window while it is locked.
Marisa
_________________________________________________
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/