Re: Problem with CuteEditor and AspxLab Menu

  •  04-12-2006, 11:19 AM

    Re: Problem with CuteEditor and AspxLab Menu

    I notified Aspxlabs of this issue and they foud it to be an issue in your code.  They have provided a workaround for this instance however this issue may pop up again when using other controls.  Please notify me if you are able to come up with a permanent solution.  The detail of the issue are below.
     

    This seems to be a CuteEditor problem (Detail explained below). You can get around this problem by inserting the following code AFTER our menu definition and BEFORE cute editor definition in your .aspx page:

    <script type="text/javascript">

    var __form;

    function aspxlab_PageSubmitNew()

    {

    __form.__formSubmitSave();

    }

    var __cf = document.forms;

    if (__cf.length >= 1)

    {

    __form = __cf[0];

    __form.__formSubmitSave = __form.submit;

    __form.submit = aspxlab_PageSubmitNew; } </script>

    Detailed explaination about the problem:

    Both our menu and CuteEditor modify form.submit so that we can hook up some code to be executed when the form is submited. Our original code is:

    function _fx_PageSubmit_Init()

    {

    var cf = document.forms;

    for (var i = 0; i< cf.length; i++)

    {

    var f = cfIdea [I];

    if (f.dm_SubmitSave == null)

    {

    f.dm_SubmitSave = f.submit;

    f.submit = aspxlab_PageSubmit;

    break;

    }

    }

    }

    function aspxlab_PageSubmit()

    {

    aspxlab_OnPageSubmit();

    if (this.dm_SubmitSave)

    this.dm_SubmitSave();

    }

    _fx_PageSubmit_Init is first called. This function saves the original submit method to new member dm_SubmitSave on the form object itself and replace form.submit with our aspxlab_PageSubmit. Then inside aspxlab_PageSubmit, we first call our code, then call the original submit.

    Note that when aspxlab_PageSubmit is called, "this" pointer is the form, since submit is a member function of the FORM object, so it should always called in the form of "form.submit();", where "form" in this expression is the form variable.

    CuteEditor does similar things. However, I noticed it saves the original submit to a separate variable, not a member of the form itself. So it's

    like:

    var formData;

    formData.m_submitSave = form.submit;

    And later on CuteEditor use this to call the original form.submit:

    formData.m_submitSave();

    Since we have already modified form.submit before CuteEditor's script runs (because our menu is defined before CuteEditor), formData.m_submitSave will point to our aspxlab_PageSubmit. However, when CuteEditor calls this function, it provides formData as "this" pointer, while our code expects "this" pointer to be form --- which is consistent with the original method because for the original submit, "this" is always the form.

    The workaround code saves the first form (We assume you only have one form in your page) into a global varialbe, and the "original" submit as a member of this global variable. We then replace the "original" submit to aspxlab_PageSubmitNew -- So that aspxlab_PageSubmitNew is the "submit"

    method CuteEditor sees.

    When CuteEditor calls our aspxlab_PageSubmitNew, regardless if CuteEditor provides the correct "this" pointer, since we have already saved the form into global variable __form, we can always use the correct this pointer to call __formSubmitSave.

    This is obviously a problem and can causes the server side view switching code to be skipped. Please confirm if this is the problem.

View Complete Thread