I am using C application with Tcl/Tk front end. I use
tcl84.lib and tk84.lib for Windows 2000 platform. I
periodically use following to refresh display and get user
input.
while (Tcl_DoOneEvent(TCL_ALL_EVENTS |
TCL_DONT_WAIT));
But this call blocks and never returns when I have modal
dialog (like file open or any other dialog) open in GUI.
When I used TCL_DONT_WAIT flag, I
assumed that this will return immediately, if there is no
event pending. But it does not work that way. Can
anybody explain why this is not working and how to
make it work?
Thanks,
Niraj
Logged In: YES
user_id=79902
Problem is (probably) that the call to the Win API to
display and run the dialog boxes is blocking. Perhaps do
this in a different thread and service events in the main
thread until a message comes back from the worker that the
dialog box has closed?
I do not have sufficient experience with the relevant API to
implement the suggestion. The failure to handle events is a
significant difference between the Win and the Unix versions
of the API.
There are also hints of "update considered harmful" in here.
Tcl and Tk *never* preempt the running of an event handler
in a way that would enable such a loop as described here to
have a guaranteed length of execution time when a particular
event handler takes a long time to execute. The way round
this is, of course, to move to an event-driven API instead.
However, again, the [tk_*] dialogs do not really fit into
such a scheme. (Adding a -command callback something like
the HTTP package would be a solution once the blocking
nature of the OS APIs has been hacked around. It'd be a FRQ
though.)
Logged In: YES
user_id=72656
See the notifier docs for Tcl_ServiceAll, especially with
respect to External Event Loops.
Logged In: YES
user_id=79902
I'm not sure that that's entirely a solution, Jeff, since
half the problem is that it is not documented whether the
event loop is running during an invokation of [tk_...] (and
in fact, this varies between platforms.)
Given this fairly significant difference, I think marking
the bug as Invalid is unhelpful at best...
Logged In: YES
user_id=72656
dup of 1038760