> However, if I press a button on the supposedly deactivated form, its
> callback still gets called when krunch and then go_cb return. In other
> words the interaction seems to be delayed, but not prevented. ...
You might try adding a fl_check_forms() call immediately following the
krunch() call. I suspect the reason for your delayed callback is that
all that fl_deactivate_form() does is to set a flag in the form's
structure -- it doesn't do anything to event masks, etc.
fl_activate_form() does much the same thing -- it just unsets the flag.
While krunch() is running the events simply queue up since XForms (and
hence, X) doesn't get control.
> Is it not a good idea to put a lengthy procedure in a callback?
Generally, yes, it is not a good idea since it blocks interactivity
and your windows don't get updated if they happen to get exposed while
the long running operation is taking place, which is aesthetically
unpleasing if nothing else.
There are a couple of ways around this.
A lot of folks fork off a separate process and communicate with the
parent process via shared memory, sockets, or some other IPC
mechanism. I tend not to like this kind of solution since it gets
complicated quite quickly.
The method which I tend to use is the idle callback. This generally
requires some amount of redesign of the algorithm in order to do small
bits of the long running process at a whack which may or may not be as
complicated as communicating via IPC. I've genned up a set of
standard routines to do this kind of thing that I use in almost all my
applications.
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/