Hi jd,
Well I've had another play around with this, and I've
got it to work, if not quite as nicely as I'd hope.
I tried adding the "swLiveConnect" parameter - it had
no effect at all. With the 'normal' (or 'old') way of
putting the movie in the page (OBJECT/EMBED tags) - it
works with or without "swLiveConnect"
With the new way - still no go.
And yep, I was trying this out with an html link, so
the timing isn't an issue.
So I fired up the DOM inspector in firefox, and just
got a handle on the flash movie there and used that.
So what I found is that whereas
function foo(){
var movie = window.document.movie_name;
movie.LoadMovie(1, "loadMe.swf");
}
works fine with the OBJECT/EMBED way, it just wont
work with the dynamic tag writing.
What does work is using document.embeds for firefox.
So though I was hoping I wouldn't have to change any
other code to implement this activeX 'fix', it looks
like I'm out of luck.
So using something like
function foo(){
var movie;
if(window.document.all){
movie = document.getElementById("movie_name");
} else {
movie = document.embeds["movie_name"];
}
movie.LoadMovie(1, "loadMe.swf");
}
does the trick. Bit weird and I don't know why it's
required, but there you go, that's what I came up with
at least. Obviously you'd make a more generally usable
function to grab a handle on the movie rather than
this hard coded example, but you get the idea.
Cheers.
jd wrote:
> I'm not sure yet, and I'd like to research this more
today... here are
> some of the things I think of offhand:
>
> -- As Stan noted, the "swLiveConnect" parameter
needs to be set... this
> was originally added to avoid unnecessary Java VM
initialization and may
> not be necessary for current browsers, but this is a
possible candidate
> for breakage.
>
> -- I haven't heard of this symptom yet, which
doesn't mean anything,
> but which does suggest that it may be a "some-or-all
files" kind of issue.
>
> -- Another possibility depends on the timing of the
communication
> call... it takes a moment for a SWF to start up and
to be able to catch
> messages from the browser, and any dynamic
tag-writing could extend that
> time... you mentioned that your triggering message
was from an HTML
> link, which makes me disinclined to credit this
hypothesis, but it's
> still a possibility.
>
> Do you have a way to check what markup the browser
actually processes,
> after the JavaScript finishes changing the markup?
Awhile ago a
> "viewsource:" protocol would reveal this, but I'm
not sure whether they
> support this anymore... if we had just the relevant
fragment in a
> simpler HTML file then it would be more accurate to
test.
>
> Sorry I don't know yet, but the above is what I have
at the moment, and
> I'll ask other staffers throughout the day today if
they have leads. Do
> any of the above potential hypotheses allow for more
targeted testing in
> the meantime...?
>
> tx,
> jd
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
