cool, thanks. I got the window.onload callback in place now, which works fine (anyway the item i need swfobject for is at the bottom of the page). so maybe I'll stick with this. I highly appreciate your little lib, but including it would even increase the javascript lib complexity we already have, which I want to avoid.
what does speak against accessing .swf through window.onload callback? will it be non-deterministic in terms of accessibility of the .swf (some browsers load faster/slower, page load time)? On 21 Jan., 14:16, "Getify Solutions, Inc." <[email protected]> wrote: > Bobby's code below is a good start, but it's not robust enough according to > what I've found in testing. For instance, in IE, there's actually a split > second where the function is "defined" on the flash swf dom object, but it's > not actually got anything in it yet (like it's an empty function value). > There are several complications which ensue. > > As an alternative to rolling your own code for waiting for ExternalInterface > to be ready, there's a library that I wrote and maintain called > CheckPlayerhttp://checkplayer.flensed.com/ which wraps around SWFObject and > adds some > additional "advanced" functionality, including in this case, > ExternalInterface availability checking. > > Basically, the strategy is to give the library a specific function name to > try to call on the swf (**caveat), which it will loop trying to do until the > try/catch around it *doesn't* fail (in which case you now know for sure the > function is ready!). Now that the readiness is detected, it calls an a > callback function you define, which notifies the rest of your code that the > SWF is fully ready to go. > > It's not the prettiest solution, but it was what I found to be most reliable > in terms of full cross-browser testability. > > My suggestion is, rather than trying to figure out these frustrations for > yourself as I did, you might consider using CheckPlayer. Otherwise, you can > look to trying to duplicate the logic I implemented for your own code. > > --Kyle > > **caveat: The only "downside" really (which is usually not a problem) is > that you have to have some function defined which is ok to be called just > plain, without any parameters, who's successful calling will not create a > problem with the state of your SWF (since it'll be guaranteed to be called > once successfully before the rest of your code continues). So, on my SWF's, > I usually have some sort of simple "Reset" or "Init" function, which doesn't > really even have to do much, but is a valid function I can call on the SWF > without using any parameters, and once it's ready, I know the rest of my > important functions are also ready. > > -------------------------------------------------- > From: "Bobby" <[email protected]> > Sent: Wednesday, January 21, 2009 6:58 AM > To: "SWFObject" <[email protected]> > Subject: Re: problems integration swfobject 2.1 and jquery (document.ready) > > > > > Your SWF and External Interface functionality will need some time to > > initialize, so calling it directly when the DOM is loaded is too > > quick. > > > You'd better only call it as soon as it is available, e.g.: > > var obj = document.getElementById("flashCookie"); > > (function() { > > if (obj && typeof obj.JStoASviaExternalInterface != "undefined") { > > obj.JStoASviaExternalInterface(); > > } > > else { > > setTimeout(arguments.callee, 10); > > } > > })(); --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SWFObject" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/swfobject?hl=en -~----------~----~----~----~------~----~------~--~---
