support async loading

[GoogleCodeExporter]

I want to use flashcanvas[pro] in a project of mine, wich loads some polyfills 
dynamically, if a feature isn't implemented.

For this flashcanvas has to support async loading.

I made the following changes to get this work:

1. Picking up options, instead of using the setOptions-method:
//CONSTATNT
var OPTIONS = window.FlashCanvas || {};

2. Configuring the path in getScript:
function getScriptUrl() {
    if(OPTIONS.path){return OPTIONS.path;}
    //...
}
3. Looking for the document.readyState-property:
// initialize canvas elements
document.attachEvent(ON_READY_STATE_CHANGE, onReadyStateChange);
if(document.readyState === "complete"){
    onReadyStateChange();
}

It would be great, if you could support async loading.

Original issue reported on code.google.com by a.farkas...@googlemail.com on 16 Jan 2011 at 3:10

[GoogleCodeExporter]

Thank you for your suggestion. I agree that it would be better to apply the 
modification of No.3.

At first, I couldn't understand why you also changed the No.1 and No.2. After a 
little thought, I understood the reason. Probably, the current getScriptUrl() 
function returns a wrong value when the script is loaded asynchronously. So, 
I'm going to modify the code so that the function will always return a correct 
value.

Original comment by revu...@gmail.com on 16 Jan 2011 at 10:20

• Changed state: Accepted

[GoogleCodeExporter]

About a bulletproof getScriptUrl: I don't know how you want to do that. But I 
suggest, that you don't relay on the filename. There are a lot of CMS, which 
will change this name.

Original comment by a.farkas...@googlemail.com on 17 Jan 2011 at 7:45

[GoogleCodeExporter]

I have committed your patch in r193 with some modifications. Could you check 
whether it works as you expect? Since I gave up detecting the URL of 
flashcanvas.js automatically, you need to set the location of SWF file in the 
following way.

document.createElement("canvas");
var FlashCanvas = {
    swfPath: "http://example.com/js/"
};
jQuery.getScript("flashcanvas.js", function(){
    ......
});

Personally, I don't recommend loading flashcanvas.js asynchronously because it 
might cause unexpected problems. For example, when I first tested your patch, 
FlashCanvas.unlock() method was never called. To make the script work, I had to 
add some wait before calling the unlock() method. But I don't know why such a 
wait is required, and I'm not sure whether the length of this wait is 
sufficient or not.

Original comment by revu...@gmail.com on 17 Jan 2011 at 2:22

[GoogleCodeExporter]

This works fine. Thanks for your help. I will make further tests to check 
wether this timer workaround makes any problems (slow connection, slow machines 
etc.). But I think, it is just weird and nothing else.

Hope to see this in next pro version, too.

Original comment by a.farkas...@googlemail.com on 18 Jan 2011 at 1:14

[GoogleCodeExporter]

I plan to release FlashCanvas Pro 1.5 in the near future. If you'd like to test 
with a pro version, here is a latest beta version that I have applied the same 
patch.

http://flashcanvas.net/archive/FlashCanvasPro-20110117.zip

Original comment by revu...@gmail.com on 18 Jan 2011 at 2:20

[GoogleCodeExporter]

I have testet the normal and default version with different 
connections/machines in IE6-IE8 and it works. Something, that, I would expect 
is, that I can set all options with the technique above and not only the 
swfPath:

window.FlashCanvas = {
    disableContextMenu: true, 
    swfPath: "http:example.com/js/"
};

Original comment by a.farkas...@googlemail.com on 18 Jan 2011 at 3:06

[GoogleCodeExporter]

Thank you for your report.

I think setting the options via a FlashCanvas object is a good idea. I'll 
implement that feature by the next release. And I keep this issue open until I 
release the next version.

Original comment by revu...@gmail.com on 18 Jan 2011 at 9:13

[GoogleCodeExporter]

Ok, thank you. You are my hero :-)

Original comment by a.farkas...@googlemail.com on 18 Jan 2011 at 11:31

[GoogleCodeExporter]

I noticed a little problem in the current implementation. If you have no 
objection, I'd like to use a window.FlashCanvasOptions object instead of a 
window.FlashCanvas object to configure FlashCanvas.

We often check the existence of a FlashCanvas object before calling a method of 
FlashCanvas, as shown in the following example.

  // Execute only when FlashCanvas library has been loaded.
  if (typeof FlashCanvas != "undefined") {
      FlashCanvas.initElement(canvas);
  }

However, if we set options via a window.FlashCanvas object, browsers other than 
IE may also try to execute the above code, and that will result in an error.

For this reason, I think using a window.FlashCanvasOptions object has fewer 
problems. What do you think?

Original comment by revu...@gmail.com on 20 Jan 2011 at 1:36

[GoogleCodeExporter]

I tentatively committed r195, which uses a window.FlashCanvasOptions object 
instead of a window.FlashCanvas object.

Original comment by revu...@gmail.com on 25 Jan 2011 at 8:53

[GoogleCodeExporter]

I've released FlashCanvas-20110201 and FlashCanvas Pro 1.5, and it seems that 
Webshims Lib 1.5.0 now supports FlashCanvas.

So, I close this issue.

Original comment by revu...@gmail.com on 19 Mar 2011 at 1:38

• Changed state: Fixed