I'm not sure it saves any cycles - not any that you'd notice.  In my 
example, we're checking if a particular variable is not void.  In your 
example, you set a timeout, but the internal runtime engine then has to (1) 
check if a timeout is defined, (2) if so, has it expired, and (3) when it 
has, clear the timeout and execute your handler.  Internally it may be 
structured a little differently (they may submit an internal event), but 
one way or another some checking is going on for something.

In either example the overhead is probably negligible, but don't away 
thinking that yours is overhead-free.  There will be checking going on - it 
just depends on who's doing the checking.  But I'm not sure you're 
necessarily saving any significant cycles.

That said, I think the whole window management thing is piss-poor, to be 
kind about it.  I just finished a release of a major product where I made 
significant more use of concurrent MIAWs than ever before.  The first 
problem is that there is no way how MIAWs are ordered.  If you have just 
one MIAW open, that's not a big deal, but if you have multiple and need 
them in a certain order, it's impossible to tell.  We had to write an Xtra 
to get the window order from the operating system.

Then, I ran into a bug that plagued us right up through release (I finally 
figured it out after we shipped - we had to disable some functionality in 
the shipping version to be safe).  The effect of the bug was that scripts 
assigned to the stage were being executed in the context of a window that 
was opening.  Definitely a Director bug, and it took me a long time to 
track it down.  It wasn't too hard to work around, but it was hell to find.

I also had to execute a lot of commands asynchronously, because I ran into 
problems with one window telling another window what to do.

So, yes, MIAWs in Director need some work, to say the least.

- Tab

At 03:19 PM 5/5/02 +0200, Alex da Franca wrote:
>At 8:03 Uhr -0400 05.05.2002, Tab Julius wrote:
>>Sorry, misread your example - you are using 'forgetwindow', a custom 
>>handler, not 'forget window', the lingo commands.  In that case yours 
>>would work, although it's a bit of the long way around to do it...
>
>but in using a timeout object it saves the cycles to check on each idle or 
>exitframe the global variable.
>many ways lead to rome...
>;-)

[To remove yourself from this list, or to change to digest mode, go to 
http://www.penworks.com/lingo-l.cgi  To post messages to the list, email 
[EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED]). Lingo-L is for 
learning and helping with programming Lingo.  Thanks!]

Reply via email to