…but not the other way around. Co-jacked, I know.
– save the JSFL file wherever you want.
– save the XML file wherever you want.
– open Flash, make sure you have a fresh FLA open, go to Commands, and choose “Run Command…”.
– select the JSFL file and click open
– select the XML file and click open
Notice that the button you click runs a JSFL function, but the function itself cannot call any native XUL methods on the control.
var fileURL = fl.browseForFileURL("open", "Select file");
var propertySettings = fl.getDocumentDOM().xmlPanel(fileURL);
<dialog id="sample" title="Sample" buttons="accept,cancel">
alert("Ok, JSFL Launched this, but I can’t access the same button that launched this code…!");
some_btn.label = "I wish this worked…";
<label value="Click the button called ‘some_btn’" />
<button id="some_btn" label="Click Me" oncommand="test();" />
I found out yesterday that Mozilla, and I think Firefox too, support this via getObjectById, or whatever. Basically you pass the object’s string name, and it’ll return the form control, just like accessing it via documents.all or however one does in IE.
…this doesn’t work in Flash, though.
Frankly, I think this is the last, important step that needs to be done to truly have JSFL make Flash extensible. A lot of custom form applications cannot be done using XML and JSFL alone… merely because the forms are only there for data holding; period. You cannot actually populate data into them in an interactive, and meaningful way. They are nice for simple text fields… but that’s it.
In the meantime, I’ll just use the Flash tag, and write a form SWF to run in a panel, but it’s still lame. After messing with XUL in Mozilla last week, it’s pretty quick compared to Flash in forms creation in my opinion. If your trying to do quick utilities, XUL is where it’s at. I hope Macromedia finishes the implementation; it’d make Flash more rockin’ than it is now.