Jumping in on this thread, my belief as to why the timing is an issue is based on the fact that the load process of the flash movie is incrementally faster under static publishing vs. dynamic publishing. This makes sense because you have to wait for the DOM to load and then javascript to swap divs before you get to the loading process, which then invokes latency and possibly external connections depending on the nature of the flash object (external XML files, etc.)
My personal workaround to this was to create a wrapper object that used SWFObject to stage a Flash movie, but allowed me to hold metadata like sizing information and flash variables statically. Depending on whether or not the flash movie was actually LOADED or not, would determine whether or not I could get away with calls to the Flash Object vs. queueing those calls until I could determine that the flash object was available for inspection. Unfortunately, because there is (as I understand it) no callback standard that says whether or not a Flash Object is really loaded and available, I end up using my knowledge of the flash object to determine whether it is in a isLoaded or isLoading state by attempting to test a specific value or somesuch. In my particular use cases, my flash objects would call an isLoaded() callback function with their id, which I could use via a management object to say, OK this guy can be messed with ad nauseum. In terms of things like staging size and other things, then it seems like the suggestion would be to wrap your SWFObject in similar code that used that delay function in Javascript (setTimeout ... there's another one that might be more appropriate, I forget) and basically says every so often, retest to see if the object is available. If it is, then execute as normal, if not, stay in the holding pattern. I don't like it so much because it sets up the notion of threads and timing in a decidedly non threaded environment, but it does the job very well for me. However, I don't have much of a QA testbed, so it could be breaking in corner cases I'm not aware of. the object hierarchy that I employed was: FlashObjectManager FlashObject --> renderSWF -> which called SWFObject --> params, attributes, flashvars where FlashObject was really a loose wrapper for SWFObject that included a "keep trying" mode if the flash object couldn't be detected. FlashObjectManager was a singleton class that kept easier track of all the FlashObjects I was instigating and centralized the ability to generate detect and remove Flash Objects from the DOM. i.e. FlashObjectManager->addFlashObject(params)... Don't know if this information is helpful in your particular case @OP, but hopefully it is. My question is would there be value for SWFObject to natively support this sort of behavior, where you could do some isLoading/isLoaded detection and capture calls to be executed once the object is loaded? Vincent On Thu, Jul 16, 2009 at 6:07 PM, Aran Rhee <[email protected]> wrote: > RE: have you ever seen the Stage sizing bug on any Flash loaded with OBJECT > embedding only? > > Yes, I have had a number of occasions where items have not been available > on frame 1 of a Flash movie with standard object/embed. This includes > flashvars, and properties like stage width/height. From memory it was only > IE which suffered from this issue. > > RE: process - Yes, swfobject does end up writing the same HTML code to the > page, but as you have found, the way the browser/plugin handles the <object> > definition being created dynamically as opposed to being defined inline on > the page seems to make a difference. The resize bug is really the only issue > that has become apparent as a side effect of this methodology. > > The onmetadata issue is the first time I have heard of this. I would have > thought that we would have heard a lot more about this as Youtube and other > video based sites use swfobject. > > > RE: HTML5 - I think you'll be waiting a couple of years there anyway :) > When is the final spec due out, 2012....? > > > Aran > > On Fri, Jul 17, 2009 at 3:18 AM, gmccomb <[email protected]> wrote: > >> >> Maybe I'm misunderstanding the process, but I was under the impression >> SWFObject (or its ilk) wrote to the HTML content of the holder (DIV, >> or whatever), basically reproducing what is in effect static OBJECT >> code. Upon completion of the HTML write, the object was passed to >> Flash, which then proceeded to load the SWF. >> >> If the OBJECT code is exactly the same (see my note in my first post >> about retrieving the HTML output of SWFObject and then creating a >> stand-alone page out of it), what is the mechanism that causes Flash >> to fail? It seems to me just about all the work-arounds involve some >> kind of deferred code execution. Does Flash run prematurely before all >> of the OBJECT code is written out by SWFO, or is there an in-browser >> timing error when running JavaScript at the precise moment the Flash >> object is being created? If the latter, it would seem to me lots of >> pages would be affected, even without dynamic publishing. >> >> Adobe could fix this, but we'll still have to write work-arounds for >> several years to come. That is, unless HTML 5 removes any need for FLV >> players! :-) >> >> >> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
