Copy link to clipboard
Copied
I'd started a discussion about a problem with a SWF file not loading an XML data file when rendered in a .NET WebBrowser control in a different forum (http://forums.adobe.com/thread/906011)
Further investigation has revealed that if the XML data file is loaded using Action Script 2 (via XML.load()), it works. But if the SWF file in question uses Action Script 3 (via URLLoader.load(), I think), the data file is NOT loaded, UNLESS the XML file is in the same folder as the HTML file.
If either SWF file is loaded using Internet Explorer 9, then everything works OK.
Are there any know issues (which would be apparently well-hidden from Internet search engines, because we've been beating on those) regarding the performance of SWF + Action Script 3 + .NET WebBrowser?
It's just so weird that there are ways to coerce the AS3 solution to work by moving files (not really an option for what we want to do), and that Internet Explorer 9 has no trouble, but the WebBrowser control (which everyone SAYS "is just a wrapper for IE") does NOT work the same way.
Any help appreciated.
Copy link to clipboard
Copied
Show code that loads XML.
Copy link to clipboard
Copied
Thanks for the reply. The code for the Action Script 2 version is here:
// xml_txt is just a dynamic field for our test
xml_txt.text = "This is a test.\n\n";
// creates an xml object
myxml = new XML();
myxml.ignoreWhite = true;// handler for after data is received (or not)
function doXML(s) {
var nodes = myxml.childNodes;
nodeCount = nodes.length;
if (nodeCount > 0) {
xml_txt.text += "Data loaded\n\n";
xml_txt.text += myxml.toString();
}
else {
xml_txt.text += "Data file not found.";
}
}// set up the listener
myxml.onLoad = doXML;
// load the object with the data file
myxml.load("test.xml");
The Action Script 3 code is:
private function getDataFile(datasource:String):void {
url = new URLRequest(datasource);
loader = new URLLoader();
loader.addEventListener(Event.COMPLETE, showData);
loader.load(url);
}private function showData(e:*): void {
// do stuff
}
In both cases, the string passed as the target file name to load is "text.xml".
Copy link to clipboard
Copied
Well, since this is a relative path - flash will attempt to load xml relative to the folder where html page is. Try to use absolute path based on swf original location.
Copy link to clipboard
Copied
While I appreciate your responses, that last one doesn't make any sense, relative to what we're seeing going on. Hard-coding a path to a file would make reuse of any routine impractical, if not impossible, if things moved on a different system (or were put on a different operating system).
We've always been using relative paths in these tests - in fact, we've always been using the filename alone, like "test.xml". AND THIS WORKS. Except for the case I've stated above. But in plain old Internet Explorer 7, and 8, and 9, we get our files working properly. Only we need to do this under programmatic control, hence the use of C# and .NET and the WebBrowser control.
We've been under the impression that the base parameter, provided to the <object> tag, would help out. And we've been putting the fully-qualified path to the location of test.xml in that parameter. It seems that it likes a trailing slash on the path. And we've tried values like "C:\datapath\datafolder\", file:///C:\datapath\datafolder\, and file:///C|/datapath/datafolder/. None help the WebBrowser running the SWF that uses AS3.
In the original discussion that I referred to in the first post in this discussion thread, I showed that we have an HTML file (located in a different folder) and it has this
<body MARGINWIDTH="0" MARGINHEIGHT="0" LEFTMARGIN="0" RIGHTMARGIN="0" TOPMARGIN="0" BOTTOMMARGIN="0">
<object type="application/x-shockwave-flash" width=100%" height="100%" id='player1' name='player1'>
<param name='movie' value='C:\data\mySWF.swf'>
<param name='allowfullscreen' value='true'>
<param name='allowscriptaccess' value='always'>
<param name='base' value='C:\data\'>
<param name='menu' value='false'>
<param name='quality' value='best'>
<param name='scale' value='exactfit'>
</object>
</body>
For our purposes, we need the SWF and XML files to reside somewhere other than the folder where the HTML file resides. And we have no problems if the XML and HTML files are in the same folder - as you point out, in that case, Flash will find the local file.
There are three really odd things coming out of this investigation:
We do appreciate the responses, though. It makes us double-check our assumptions and statements.
Copy link to clipboard
Copied
1. If html page that uses this embed code is in, say, directory
c:\bin\
swf will request xml from the same directory because once Flash is embedded - browser takes over and sends requests relative to the page that is displays.
c:\bin\text.xml
2. "Hard-coding a path to a file would make reuse of any routine impractical"
Yes, it is true but no one proposes doing it. What I suggested was to use dynamic absolute path and to calculate/compose it based on the original swf location that you can read from LoaderInfo.
Copy link to clipboard
Copied
The problem with your second suggestion is that I don't control the SWF files being used. They look for a non-pathed file (i.e. filename only). That's why we supply the base parameter to the <object> tag.
Your first statement makes sense to me, but our practical experience shows us that Internet Explorer 9 (and 8) WILL render the HTML files properly, finding the SWF file and having it load the XML data file properly. That's with the HTML file (with a fully-qualified base parameter as part of the <object> tag) in one folder, and the SWF and XML files together in a separate folder.
The behavior we see in the WebBrowser DOES seem to match your first assertion. Except - not in the case of AS2, but only in the case of AS3. That's with the full base parameter info - the same file that works in IE9 does NOT work in my program using WebBrowser.
I don't think the problem is in how we're doing things - like I say, it works in IE9. I think the problem exists in either the WebBrowser component or the Flash OCX control. Something isn't working as documented.
Unfortunately, both companies want you to pay up front to report a bug to their technical support people. Maybe I'll have to resort to that. I'm just trying to isolate which component is the most likely culprit, so that I can approach that company first. I'm expecting a certain amount of finger pointing. I'm thinking more Microsoft right now, since the IE9 experiment works, but the WebBrowser fails.
Copy link to clipboard
Copied
Well, if there is a certain dynamism in xml location - there are always FlashVars to direct the right way.
I am not so sure about base parameter. I will check it later but if memory serves me correctly, it is a legacy entity and it is buggy. I will check it out later.
Copy link to clipboard
Copied
I'd appreciate any concrete insight you can give into the Flash stuff. I'm really the WinForms developer, and we really just expected to consume these files in the WebBrowser (because "everything works in IE"... that's become our lament with respect to this problem).