All,
What timeout object stuff has changed?
Were the changes good/bad/indifferent?
I know Roy already gave a bit of information in response to this but I
wanted to add a little extra (ok, a _lot_ extra) so that the whole story is
clear as more has changed than just timeout declarations. This is supposed
to be going up as a tech note I believe but I didn't find it in a search
just now so I'll make sure and give them a reminder. This information is not
in the documentation because the addition of the scriptExecutionStyle
property (discussed below) happened in response to beta site feedback and
careful thought, unfortunately all that happened after our documentation
deadline. Therefore we decided that while it's a signifcant problem that
this stuff isn't in the manuals, it would have been far worse to ship
without some of what I'm going to describe (read on and you'll understand a
bit more).
Director has many top-level functions that are used to obtain references to
various elements in Director's object model. In previous releases (MX and
earlier) all of these top-level functions behaved differently when the
specified object didn't exist:
member(foo) - returned member -1 of castLib 1
script(foo) - script error
sprite(foo) - returned sprite(1)
timeout(foo) - created the timeout object
window(foo) - created the window object
xtra(foo) - script error
Instead of having those all behave in their own way (say hello to another
Lingo-ism which causes people to think it's not a robust professional
language), we thought it would be best to make them consistent in that if
you use these top-level functions and the specified object doesn't exist,
they will all return VOID instead of the results above. This change has
repurcussions that must be considered as the behavior of all these functions
when the object doesn't exist has changed. In some cases (member(),
script(), sprite() and xtra()) the change is to your error checking code
if/when you attempt to verify that you got a valid return value (i.e. when
you query a member by name, don't check for it to be member(-1,1), check for
the return value to be VOID). For the others (timeout() and window()) this
has forced a change to how you create these objects.
In MX and earlier when you create a timeout or a window object the syntax is
as follows:
tTO = timeout(foo).new(50,#someHandler,0)
tWin = window(blah)
Then in the case of the window you might also do things like:
tWin.open()
-- or
window(blah).open()
But remember that in MX'04 if the object doesn't exist (which is doesn't as
you're trying to create it, right?) then the above code will fail:
tTO = timeout(foo).new(50,#someHandler,0)
-- the above is really executed as:
tTo = (VOID).new(50,#someHandler,0)
And VOID has no new() method so you'll get a script error (object expected).
The same is true if you try to open the window (VOID doesn't have an open()
method either). Therefore in the new way of doing things in MX'04 you have
to adjust the syntax for timeout and window object creation:
-- Lingo
tTO = timeout().new(name,period,handlerOrFunction,targetData)
tTO = new timeout(name,period,handlerOrFunction,targetData)
// JS Syntax
tTO = new timeout(name,period,handlerOrFunction,targetData)
But wait a minute here, I thought I mentioned something called
'scriptExecutionStyle' up top, where's that? Well, we made the changes above
and sure enough content broke. There are many movies out there that
currently use the old code and if they were played in the new version 10
player (auth, projectors or Shockwave) they would fail with script errors
because the code hadn't been updated. Naturally this caused everyone a great
deal of concern and so we had to implement the ability for folks to revert
the behavior of these top-level functions to their MX-and-earlier behavior.
Enter scriptExecutionStyle (again, enter it after our documentation deadline
:( )...
Each movie has a property associated with it called scriptExecutionStyle,
this property takes integer values and the value it contains affects how
those top-level functions behave (plus a few other items I've mentioned
below). If you set the scriptExecutionStyle property to a value less than or
equal to 9, then the top-level functions will revert back to MX-and-earlier
behavior so as not to break your old content. If you set the
scriptExecutionStyle to a value of 10 then the top-level functions will
behave in the new MX'04 way. Movies authored in MX and earlier will have a
default scriptExecutionStyle value of 9 so as to maintain old behavior, new
movies authored in MX'04 have a default value of 10 to encourage using the
new behavior. You can change the value of the property in your movies at any
time you like using the following syntax:
_movie.scriptExecutionStyle = 9
There are other ways to access movie objects besides _movie, the above is
only one example. There are no user interface elements for this property,
you'll have to use code (message
