SWFObject instantiates fine. i don't have a quickie answer for you... sorry. :)

in this type of scenario, path issues often pop up. this happens most frequently with 'player' SWFs like the one you're trying to use (a video player).

the player SWF needs to load the target file (FLV in this case); when the 'player' SWF looks for the FLV, it checks the path you gave it relative to the 'player' SWF, not relative to the HTML page the player SWF was embedded onto.

to eliminate path issues, try using the SWF's absolute URL in your XML file and the absolute URL for your FLV in your 'player' SWF.

you can also try embedding the SWF without using the XML file. this will help isolate the problem (removes xmlhttprequest from the equation). set the onclick for the 'video' link to load the swf directly:



<li><a href="videos/BBC_VOMT.swf"
onclick="loadSWF(this.href); return false;">BBC VOMT 2002</a></li>

function loadSWF(url){
var so = new SWFObject(url, "flashVarsExample", "550", "400", "8", "#FFFFFF");
so.write("contentinner");
}



frankly, i'm not sure why you're using xmlhttprequest in this instance... from a usability perspective, if the visitor doesn't have JavaScript enabled, the xmlhttprequest method denies them all access to the SWF. if you use the method i just described, if the user had JS disabled they will still be able to view your SWF by clicking the hyperlink (assuming they have Flash installed).

- philip

PS - extra observations:
you have a typo. div id-"right" should be div id="right"

when declaring a SWFObject instance, even if you want it to be transparent, you should specify a background color. i'm not 100% sure if it's required, but i think it helps maintain consistent coding practices. besides, if you use wmode=transparent, the bg color you specify will be ignored, anyway. doesn't hurt. :)

hi gayle

usng the example in my last post won't cause the SWF to load in a new page; the SWF will load into the "contentinner" target DIV. the SWF would load in a new page ONLY if the user has JavaScript disabled (if they have JS disabled, 'onclick' will not work). this is a best practice, as it makes the site more accessible, yet still provides the whiz-bang experience for users who have JS enabled.

(as an aside, if you want to read more about this line of thinking, i highly recommend Jeremy Keith's two books: DOM Scripting and Bulletproof Ajax. they're easy to read and a great primer for less experienced developers.)

the ajax example i wrote on my site doesn't promote an XML file containing the SWF parameters as 'the answer'... it's much easier to specify SWFObject parameters directly in JavaScript and avoid xmlhttprequest entirely. my example was just illustrating a way of getting ajax and SWFObject to play nice together since some people had been posting questions about the topic on this forum.

having seen what you're doing with this site, i don't think you need to use xmlhttprequest for loading your SWFs. perhaps it's needed for other content such as HTML pages, but not SWFs.

regarding the 'path' issue: what URL did you use for the FLV when you made your SWF? if you used something like "videos/BBC_VOMT.flv" instead of "BBC_VOMT.flv", your video will NOT load correctly when loaded into the HTML file.

assuming this is the file structure of your site:

loren/index.html
loren/videos/BBC_VOMT.flv
loren/videos/BBC_VOMT.swf
loren/videos/BBC_VOMT.xml

the FLV should be specified relative to the SWF, not relative to the HTML file. so the FLV's path should be specified in the SWF as BBC_VOMT.flv, not videos/BBC_VOMT.flv.

what i was suggesting earlier is simply to use absolute URLs in an effort to eliminate any confusion about the file paths. if you use http://www.gayleamy.com/loren/BBC_VOMT.swf and http://www.gayleamy.com/loren/BBC_VOMT.flv, you'll be certain the file paths you specified aren't the cause of your problems.

- philip

here's a working example of using an onclick event to load a SWF into a specified DIV: http://www.pipwerks.com/lab/swfobject/load-onclick/index.html

you should be able to modify this example to suit your needs. :)

- philip

Okay... That was very, very helpful! Thank you, and bless you and all you come into contact with on a daily basis. ;)

Now, however (sorry, there IS a "however"), the file is showing up without the skin; ie: the player controls. I'm sure there's probably a flashvars part of the coding that I need, but I'm still a little lost at this point...

Guidance? (Thanks again for your help!!!)

You can see it at: http://www.gayleamy.com/loren under "videos" and the first link.

Gayle

your FLV player isn't showing the player skin because the skin can't be found. the player skin is contained in an external file named "SteelExternalPlaySeekMute.swf"; somehow the player SWF can't locate the 'steel' SWF. this gets back to file paths... if you can specify the absolute path for the 'steel' SWF in your player SWF, everything should be fine.

you could also ditch the FLV player you're using in favor of something else. the free JW FLV Player is really popular and easy to implement. it works really well with SWFObject and javascript.

http://www.jeroenwijering.com/?item=JW_FLV_Player

sorry, i neglected to mention that if you use the JW FLV player, there's a wee bit of trickiness in setting up the URL. BUT... it isn't a huge deal, so i wouldn't sweat it. i'll try and explain it.

here's a working example you can follow:
http://www.pipwerks.com/lab/swfobject/load-onclick/jw-FLV2.html

(BTW, you need the FLV player, which is a different SWF than the MP3 player)

first, i renamed the "loadSWF" function to "playFLV" since that's specifically what we're trying to do. we still pass the SWF's URL as a parameter.


function playFLV(playerURL){
var w = Number(playerURL.split("width=")[1].split("&")[0]);
var h = Number(playerURL.split("height=")[1].split("&")[0]);

var so = new SWFObject(playerURL, 'flvPlayer', w, h, '7', '#000000');
so.write("flashcontent");
}


you probably noticed the new "var w =" and "var h =" stuff. i'll explain them in a moment.

also note that i didn't set up any of the optional JW settings, such as autoplay or default image. you can add those later.

next up we have the rebuilt link for users to click.


<p>
<a href="/lab/_common/flvplayer.swf?height=400&amp;width=550&amp;file=/lab/swfobject/load-onclick/video.flv"
onclick="playFLV(this.href); return false;">
Click here to load the SWF!</a>
</p>


the onclick attribute is pretty straightforward, almost exactly like your previous function. the function "playFLV" is still passing the href of the link. the big change is what's contained in the href.

the href was changed to this long-winded URL:

/lab/_common/flvplayer.swf?height=400&width=550&file=/lab/swfobject/load-onclick/video.flv


why? because unlike your previous FLV player, the JW player doesn't have the FLV file's location hard-coded into the player. with the old SWF, the FLV location was hard-coded into the SWF, so we could just link to the SWF and it would load the external FLV with no extra configuration work. with the JW FLV player, we have to link to the JW SWF, then pass the FLV location (and other JW config settings) to the SWF using a querystring (?height=400...).

it's a little extra work to set up the querystring, but doing it this way ensures browsers with javascript disabled will still be able to watch the video!

the cool thing is that we can now automate the 'playFLV' function to grab the info from the querystring and automatically insert the SWF size into the SWFObject declaration for us. (the "var w =" and "var h =" tidbits.) this means you can use different sized FLV files and not have to recode your SWFObject declaration each time you load a new FLV.

the normal SWFObject implementation of the JW player (the one shown in the JW FLV player's documentation) includes the line

addVariable("file", "video.flv");


what we're doing in this instance is using the querystring -- NOT SWFObject's addVariable method -- to pass the "file" data for us, which means we don't need to set up any addVariable lines in SWFObject. it simplifies the process for us.

please note that i entered both the FLV URL and the SWF URL as site-relative links, which are shorter than absolute URLs but more reliable than document-relative URLs. this is an important point because the file to be played has to be listed relative to the flvPlayer.swf file, NOT the HTML file it loads into. using site-relative links means i don't have to worry about it. you could also use absolute URLs.

also note that you should use the entity & instead of the character & in querystrings to avoid issues with XHTML doctypes.

hope this makes sense... :)
- philip

you hello I want to men friend ,trcut me , you can see me
www.ConnectAsia.info/en/lang104082about_lili11
thank you

Check http://www.asual.com/swfaddress/samples/coherence/#/portfolio/1/

It loads http://www.asual.com/swfaddress/samples/coherence/datasource/portfolio1.xml via XHR and uses the following code to embed the response:

function updateContent(html) {
var content = document.getElementById('content');
content.innerHTML = html;
while (html.match(/(<script[^>]+javascript[^>]+>\s*(\/\/*<!\[CDATA\[)?(<!--)?\s*)/i)) {
html = html.substr(html.indexOf(RegExp.$1) + RegExp.$1.length);
if (!html.match(/((\/\/ *\]\]>)?(-->)?\s*<\/script>)/)) break;
block = html.substr(0, html.indexOf(RegExp.$1));
html = html.substring(block.length + RegExp.$1.length);
eval(block);
}
}
updateContent(xhr.responseText);