It's set up as:
myWindow =window("myWindowName")
tell myWindow
-- whatever
end tell
Either way should work. If anything, I think the FIRST one would work
better, forcing it to resolve the name every time, but as far as I'm
concerned they BOTH should work.
And they DO work, in authoring and Mac, but the flakiness is in
Windows. This is consistent with how when a MIAW forgets itself it'll
crash a projector but not in authoring. Authoring and runtime Windows have
different internal window structures. The annoying thing, obviously, is
that it doesn't happen in authoring, making it a pig to debug.
I have been looking at this a lot over the last number of weeks, and it is
definitely related to when a window tells another window to do
something. If a subwindow tells another subwindow to do something and to
move itself and so forth, often messages get confused and get sent to the
wrong window. If I make it asychronous, where the first subwindow logs a
request and the stage does the telling (from the context of the stage) then
it is much safer and unlikely to crash. However, in theory a window SHOULD
be able to tell another window to do something and/or move and not have
Director get confused. Since it's the same code shared, and it works on
Mac and works in authoring, I'm pretty sure it's a problem in Director Win
runtime engine implementation of window management not keeping everything
up to date, but I'm looking to see if anyone knows the exact details of
what's wrong (that is, it's related to moves, or related to tells, or to
tells within tells) so I know what to eliminate. It's too large of a
program to rework overnight, so I'm just trying to find the specific cause,
and was wondering if anyone else had run across it.
- Tab
At 10:52 AM 3/29/02 -0500, Colin Holgate wrote:
>>Of course I use variables for the wins and not actual string specs every
>>time.
>
>
>Are you saying:
>
>windowsname = "this window"
>tell window windowsname to dothis
>
>
>or:
>
>thatwindow = window("this window")
>tell thatwindow to dothis
>
>?
>
>The second approach might keep up with any shuffling that goes on.
[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!]