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 or script window) to change the property's
value. We chose to make this an integer value so as to provide flexibility
going forward (maybe we do other changes and you need to revert from 11 back
to 10, or to 9, or to ???). As it is now, your only real options are 9 or
10.
As I hinted at just above, there are a few other items affected by the
scriptExecutionStyle property because of other changes we made this release:
- we've changed rgb(r,g,b) to color(r,g,b), using a more generic color
object is cleaner going forward; scriptExecutionStyle of 9 you use
rgb(), set it to 10 and you use color()
- in MX'04 the stage is a window just like MIAW's, part of that change
is that the stage window is now *always* in the windowList (even in
Shockwave!), if you set the scriptExecutionStyle to 9 the stage will
not appear in the windowList at all, set it to 10 and it will always
be there
- the format of the xtraList property was changed so that if the
scriptExecutionStyle is 9, the list contains a #name property, set
the property to 10 and the list has a #fileName property
We encourage folks to write any new content that is not going to be
published to the SW8.5 format using the new syntax options, but while
working on old content leave things as they are and only begin the updating
process when you're ready to do so. This property takes affect in all
environments and was added to help protect old movies under the new player.
This email is going to be sent along to our support team as a gentle
reminder that this needs a tech note ASAP if it's not already in the works.
NOTE: I'm out of the office all next week on vacation so I may not be online
to handle any follow-up questions after today. I'm giving you the heads up
so you don't think I'm ignoring you if I'm not on this list next week. And
no, I will _not_ be spamming you folks with an auto-responder. ;)
Cheers,
Tom Higgins
Product Specialist - Director Team
Macromedia
Director MX 2004 - NOW SHIPPING!
Industrial-Strength Multimedia
www.macromedia.com/software/director
...
[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!]
