onreadystatechanged and IE8

[GoogleCodeExporter]

With IE8 and drawing code inside the jQuery document ready event, the
drawing code will sometimes be run before excanvas init_ is called so that
drawing fails on IE. I posted a longer description here:

http://groups.google.com/group/google-excanvas/browse_thread/thread/7e2065266af1
cedd

The gist of it seems to be that if the drawing code starts by calling init_
itself, then it'll work.

It would be nice if this was documented, and perhaps aliased into something
more meaningful.

Original issue reported on code.google.com by olau%iol...@gtempaccount.com on 28 Apr 2009 at 5:32

[GoogleCodeExporter]

This still seems to be a problem over a year later. Is this project dead?

Original comment by m.saturn...@gmail.com on 19 Aug 2010 at 4:27

[GoogleCodeExporter]

I'm surprised to see that this was actually fixed in r58 (the commit that added 
text support). Now the stylesheet stuff is added in initElement too. r58 was 
funny enough committed a week before I opened this issue. :)

So please close this again.

Original comment by olau%iol...@gtempaccount.com on 16 Dec 2010 at 8:19

[GoogleCodeExporter]

Original comment by erik.arv...@gmail.com on 24 Mar 2011 at 5:42

• Changed state: Fixed

[GoogleCodeExporter]

I'd like for this ticket to be reopened as I'm not convinced that it's fixed. 
In excanvas.js r73, initElement still isn't called on any static CANVAS 
elements until "onreadystatechange". This apparently happens after 
$(document).ready() is called by jQuery, which makes drawing in the 
jQuery-document-ready function impossible. My workaround has been to use the 
following code before manipulating the canvas in my jQuery-document-ready 
function:

// Make sure Internet Explorer can use the canvas if it wasn't already
// detected
if(window.G_vmlCanvasManager)
    window.G_vmlCanvasManager.initElement(canvas);

Original comment by chro...@gmail.com on 3 Apr 2011 at 4:20

[GoogleCodeExporter]

chromus: I think you're seeing a different issue. I was referring to the 
internal initialization in the library - before this was fixed the code you 
just posted would have a race condition (the reason I know this is that I used 
the exact same code in Flot with dynamically generated canvases).

I'm not sure the issue you're seeing is fixable. I think it was a mistake to 
try to guarantee that the canvas elements were ready in the first place, at 
least without a really bullet-proof solution. Anyway, if you want to pursue it, 
I suggest you open another issue. :)

Original comment by olau%iol...@gtempaccount.com on 4 Apr 2011 at 9:14

[GoogleCodeExporter]

o...@iola.dk: I read your initial description of this issue as the exact same 
problem I was having since I was attempting to draw to a CANVAS before 
G_vmlCanvasManager.init_ was called. I agree with you, however, that it's 
probably a better solution to explicitly initialize every CANVAS (static or 
dynamic) instead of relying on excanvas to automatically initialize it for you. 
My ideal outcome would be updating the documentation to reflect this and 
removing the auto-initialization.

Original comment by chro...@gmail.com on 5 Apr 2011 at 1:36