70
Programming with TIDE
©2000-2008 Tibbo Technology Inc.
Above we have the same two chains of procedures which appear under
, with one noticeable difference: Procedure C includes a
doevents statement. The on_event_1 chain takes up 11 bytes. But on_event_2 and
procedure C (which together take up 5 bytes) cannot share the same space with
the on_event_1 chain, because when the doevents statement is invoked, the state
of variables for on_event_2 and procedure C must be preserved. So these two get
their own exclusive memory space.
Procedure D, which is also a part of the on_event_2 chain, does not get its own
exclusive memory space. This is because it comes later on the chain than the
procedure which contains the doevents statement. There will never be a situation
where the variables of procedure D must be preserved while other chains are
executing.
Thus, the total memory requirements of the project depicted above would be 16
bytes -- 11 shared bytes plus 5 exclusive bytes. This is more than would have
been required had we not used doevents.
Sharing Procedures Which Utilize Doevents
Procedures which contain doevents statements, as well as all procedures which call
them (directly or through other procedures) cannot be shared between chains.
Let us say event handler on_event_1 calls procedure A. Procedure A calls
procedure B. Procedure B contains a doevents statement, and also calls procedure
C.
Next, we have event handler on_event_2. It cannot call procedure A or B, because
procedure B contains a doevents statement (and A calls B). If it could call
procedure A, we might get a situation whereby event handler on_event_1 fires,
calls procedure A. In it, procedure B is called, and doevents is executed. During
doevents, an event handler on_event_2 fires, and calls procedure A again -- while
the previous instance of A still holds variables in memory, waiting for control to
return to it. This would corrupt the values of variables used by the first A (if you
try to do something like this, the compiler will raise an error).
66