Actually, to be honest, I was flipping through the pdf earlier yesterday and shot off that message before I read the whole thing as well as Mark's great article on devnet detailing the minutiae of working with new flash elements. Really great that we can proxy event messages from components and forward them to director handlers pretty effortlessly.
Changing gears for a second...
One question I did have is that he mentions that 'actionscript-heavy' items should have their own player and not be used in the same player as some other elements to prevent problems.
A.) What is defined as 'heavy' actionscript?
and
B.) Are there any specific gotchas/namespace collisions etc... we should look for when utilizing commonPlayer?
I actually had a problem in director a year ago (that I believe I mentioned here) where we were duplicating a list of clips containing dynamic text which was passed into flash from a Valentina database that could be clicked to send messages back to director. Could be construed as AS-heavy I guess... I got it working, but during QA we found many inconsistencies and instability in that section. After 'flattening' the flash and making it non-dynamic the problems went away.
Another issue that couldn't be verified by tech support with a simple case was issues when loading flash from cd-based media when played in a very old dvd-rom drive. We consistently had problems where (only after 20+ minutes) streaming flash audio in any of a dozen simple animations with voiceover would start stuttering, ruining the continuity of the animation. Even after completely disposing of all flash sprites on the stage and going to another screen with flash, the stuttering would reappear, even when using the most recent flash asset xtra...Leading me to believe it was an issue with an instance of the flash player, as best I could surmise.
The workaround was quite a pain - basically having to invent a cuepoint system and sound manager just to keep flash in synch with audio playing in director. Don't know if these issues seem totally wacky or alien to everyone, but we were able to confirm on multiple pieces of hardware and OSes. I will say, though, that more simple, less AS-laden swf files have performed perfectly, even with internal audio. I will try to test as exaustively as possible with the problem projects and post a message if we get any of the same issues.
Thanks, ~Mathew
Thomas Higgins wrote:
What other thoughts do people have about using this new feature in DMX2K4?
Wow, this is _not_ a new feature. Welcome to Director MX functionality!!! We introduced Flash Objects From Scripting as a feature last release, it is the feature that allows you to create and use various Flash objects in Lingo (and now JS) directly, with or without a Flash sprite.
Here's a demo to get you started on exploring this (awesome) ability specifically with LocalConnection objects:
<http://poppy.macromedia.com/~thiggins/flash_integration/localconnection_sim plechat/index.htm>
Source code provided, authored in MX many moons ago. :)
LocalConnections can be used for any sort of Flash-Director-Projectors-Shockwave intercommunication, it just doesn't matter! I've had a "chat" going between Director authoring, a Shockwave movie in a browser, a Director projector, a Flash projector and a Flash SWF in a browser, all exchanging text via LocalConnection objects. It's really sweet once you figure it out (and it's _really_simple_ to use if you ask me).
It seems you can use this messaging layer as an alternative to using 'tell' to communicate across LDMs, MIAWs,
If you're in MX 2004 why not do these instead of using tell or LocalConnections:
window("foo").movie.someHandler() window("foo").movie.castLib[2].member["foo"].property
Both of the above are now possible in MX 2004 to bypass the use of tell statements (implement JS engine, clean-up object model, expose movie objects [among others], bam! Whole new world opens up for both JS and Lingo users).
Cheers, Tom Higgins Product Specialist - Director Team Macromedia
[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!]
