Adam,

 

The problem is related to initial page load, not dynamically creating the editors within an alrea

 

When the client browser loads the cute editor, especially IE, it begins execution before the entire page is loaded.  The cute editor requires us to redefine the stub version of CuteEditor_OnInitialized and any other client side function we wish to implement after the cute editor within the page.  The problem this causes is that, if the initialization of the cute editor completes before the bottom portion of the page is loaded, the stub version fires rather than the event at the bottom of the page.

 

I've proven this out by putting an alert inside the cute editor code itself and refreshing the page repeatedly in IE.  If you remove the alert("Event Fired!"); from my example and put this in your CuteEditorImplementation.js and/or Loader.js inside the "function CuteEditor_OnInitialized {}" stub function, this alert will fire occasionally upon repeated refreshes within IE.

In more slower loading pages, the problem becomes worse.

In order to fix it I had to put an initialization function at the top of the page, like:

 

<script language='javascript'>

function InitializeEditor(editor)

{

    // Do Something

}

</script>

 

And then change the cute editor stub function within Cute Editor from:

 

function CuteEditor_OnInitialized {}

 

to:

 

function CuteEditor_OnInitialized { if( typeof(InitializeEditor) == "function") InitializedEditor(editor); }

 

I don't want to have to constantly change the cute editor code every time there is an update to guarantee that I get an event fired.

 

If the cute editor waited until the entire page was loaded prior to firing the function, this would not be a problem.  As it stands now, this method does not guarantee that my initialize event is fired.