Adobe Community: Bizarre XML access behavior in .NET WebBrowser between Action Script 2 and Action Script 3

Currently Being Moderated

1. Andrei1,

Sep 30, 2011 3:00 PM in reply to GuyWithDogs_WA

Report

Show code that loads XML.

|

Mark as:

Currently Being Moderated

2. GuyWithDogs_WA,

Sep 30, 2011 3:40 PM in reply to Andrei1

Report

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".

|

Mark as:

Currently Being Moderated

3. Andrei1,

Sep 30, 2011 4:10 PM in reply to GuyWithDogs_WA

Report

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.

|

Mark as:

Currently Being Moderated

4. GuyWithDogs_WA,

Sep 30, 2011 4:27 PM in reply to Andrei1

Report

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:

The WebBrowser behaves differently than Internet Explorer, so it isn't "simply a .NET wrapper around the IE functionality". I'm talking to Microsoft about this, because I think the problem likes mostly there. These files work in IE, but not in the wrapper (WebBrowser).
There's a difference between AS2 and AS3 in how an XML file is loaded, at least with respect to the WebBrowser control. And that may be an Adobe thing, or it may be a Microsoft thing, or it may be a combination of the two.
We can't believe we're the only people who have run into this, given the number of posts we've seen with people asking about Flash in WebBrowser and loading XML in Flash.

We do appreciate the responses, though. It makes us double-check our assumptions and statements.

|

Mark as:

Currently Being Moderated

5. Andrei1,

Sep 30, 2011 5:13 PM in reply to GuyWithDogs_WA

Report

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.

|

Mark as:

Currently Being Moderated

6. GuyWithDogs_WA,

Sep 30, 2011 6:21 PM in reply to Andrei1

Report

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.

|

Mark as:

Currently Being Moderated

7. Andrei1,

Sep 30, 2011 6:39 PM in reply to GuyWithDogs_WA

Report

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.

|

Mark as:

Currently Being Moderated

8. GuyWithDogs_WA,

Sep 30, 2011 6:45 PM in reply to Andrei1

Report

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).

|

Mark as:

ActionScript 3

Bizarre XML access behavior in .NET WebBrowser between Action Script 2 and Action Script 3

Sep 29, 2011 4:15 PM

More Like This

Bookmarked By (0)

Answers + Points = Status