David Fedor <[EMAIL PROTECTED]> writes:
>This way of handling events (nested event loops) is generally a risky
>thing. If for example your event loop is trying to grab some events and
>special-case them, it won't work in this case. And you're not calling
>MenuHandleEvent or FormDispatchEvent like your real event loop would... so
>some events might not get handled properly.
But would your real event loop be calling MenuHandleEvent or
FormDispatchEvent if the current Form was already opened and initialized,
and had absolutely no Menu or other Form UI objects to handle, except for
one, big, full-screen, cancel-busy-calculation-loop pseudo-button...?
Actually, FormDispatchEvent will have to handle closing the form, but that
can only happen after first canceling the calculation, which should then
exit the inner event loop well before any close event.
I think it's possible to organize an application so that two event loops
have no overlap in handling any given event and also have no paths
that could lead to event loop recursion, except for possibly appStopEvent
and SysHandleEvent (and appStopEvent can be handled by setting a global
flag variable to signal the calculation loop and both event loops). So,
Palm, what other kinds of problems can occur from a nested event loop
calling SysHandleEvent?
This is actually an important question. Although all recursive
computations
can *theoretically* be broken into sequential blocks with global state
(the
type that could get called in temporally small chunks from an event loop);
in practice this makes certain algorithms much harder to understand (and
thus very possibly undebuggable).
--
Ron Nicholson
HotPaw
http://www.hotpaw.com/rhn/hotpaw/
