Ian MacArthur wrote:
> But I still think the example was wrong - wedging in a callback is a Bad
> Thing to do.
Right, but let's say the callback just did:
x += y * z;
..but if the box suddenly started swapping during that operation,
it could end up taking 5 seconds to run, and events on the button
invoking the callback could queue up.
In a mission critical app, it would be important to make sure
the button invoking it was deactivated, and while it is, any
events are ignored.
A situation I myself have run into in the past (not with FLTK,
but with a keyboard buffer) is an app that has two buttons to
"crawl" a motor forward and back.
The motor controls an $80,000 camera carriage, and the camera
operator needs to "inch" the camera's macro fish-eye lens
right up to a model of a steel spaceship, so close as to
almost touch it. The model took 10 people weeks to build.
I can see the user clicking the 'inch forward' button
to get the camera right up to the model, and just when they're
a few clicks away, the host OS suddenly freezes up
("Hey, it's time for a microsoft windows update!!")
and the user would keep clicking for a second or so before
realizing the app isn't responding, then takes their hand
off the mouse, and watches in horror as the app wakes up,
and handles all those queued clicks, and inches the lens
right through the model.
I think to demonstrate that situation, the OP's sleep is
a good one, and deactivate/reactivating the widget makes
a good way of preventing it, assuming the events are processed
before the re-activation.
I can't actually think of a better way to demonstrate it..
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
