How are you creating 'play' and 'stop' methods via ExternalInterface?

  • 1
  • Question
  • Updated 7 years ago
  • Answered
Hi, I'm a developer working on Glow, a JavaScript library http://www.bbc.co.uk/glow/

Anyway, we've got methods to embed Flash movies, but we get an error in IE when the Flash movie tries to expose methods named 'play' or 'stop'.

This issue isn't unique to Glow, as there are other references to it online, eg http://dev.nuclearrooster.com/2008/07...

However, you guys clearly don't have that issue. Did you knowingly fix this issue, or did you not have it in the first place?

Cheers,
Jake.
Photo of Jake Archibald

Jake Archibald

  • 2 Posts
  • 0 Reply Likes

Posted 7 years ago

  • 1
Photo of Scott

Scott, Official Rep

  • 3873 Posts
  • 253 Reply Likes
Official Response
Interesting. The blog post includes some obvious reserved javascript keywords in IE which are known to be problematic, "tags" is one of the odd ones. Same with "all", and a few other common words. It's likely blowing up from syntax such as object[property](param) within ExternalInterface, which when property = "length", for example, you can see how things go wrong.

It's possible that play and stop are reserved for the Flash activeX control in IE for some silly reason, perhaps a legacy Flash control method or an ActiveX behaviour. In any case, my recommendation is to use a prefix or naming convention to avoid conflicts with common words/methods like this.

Flash injects some magical Javascript (for the ExternalInterface) feature into the browser, which is how the Flash-to-JS communication works. Effectively it's serializing and deserializing your method calls to/from XML. If you're curious, look at Firebug's DOM tab for functions like __flash__functionName for the details on a page using Flash + JS. It's rather nutty, but i digress.

In my case, the Flash side exposes methods (via addCallback) to the soundManager controller following an underscore naming convention, eg. _createSound(), _play() and so on (see flash 8 .as source, externalInterface addCallbacks at bottom of file.) I guess I unknowingly avoided collisions by using this convention.

For the user-facing API, wrapper methods eg. SMSound.play()/pause() and so on exist in JS, which ultimately end up calling soundManager.flashMovie._play() etc.