.net - jQuery Dialog-Postback but UpdatePanel doesn't get updated

Question

i want to show a jQuery UI Dialog from Codebehind and need to refresh it after postbacks.

The dialog is a control to filter and find data. So the user selects from DropDownLists and enters text in TextBoxes, clicks a "Apply-Button", an asynchronous postback happens, the data gets filtered according to the user's selection and the result will be shown in a GridView. Therefore i need to update the UpdatePanel around the GridView.

The asynchronous postback works with help from these links:

• jQuery UI Dialog with ASP.NET button postback
• http://blog.roonga.com.au/2009/07/using-jquery-ui-dialog-with-aspnet-and.html

(Basically the dlg.parent().appendTo(jQuery("form:first"));-Solution)

Problem: I cannot update the UpdatePanel neither with UpdateMode="Always" nor manually from codebehind via UpdatePanel.Update(). I assume that it has something to do with the Dialog not being inside of the UpdatePanel or something similar. Hopefully somebody can help me along.

Some source:

function createChargeFilterDialog() {
    //setup dialog
    $('#Dialog_ChargeFilter').dialog({
        modal: true,
        resizable: false,
        autoOpen: false,
        draggable: true,
        hide: "Drop",
        width: 850,
        height: 600,
        position: "center",
        title: "Charge-Filter",
        buttons: {
            "Close": function () {
                $(this).dialog("close");
            }
        },
        open: function (type, data) {
            $(this).parent().appendTo(jQuery("form:first"))
        },
        close: function (type, data) {
        }
    });
}

It gets called from codebehind when BtnShowDialog(outside the jQuery-Dialog) gets clicked via

AjaxControlToolkit.ToolkitScriptManager.RegisterStartupScript _
            (Me.Page, GetType(Page), "showChargeFilterDialog", "createChargeFilterDialog();$('#Dialog_ChargeFilter').dialog('open');", True)

Update: i've also noticed a problem in the postback-values. All TextBoxes if empty or not have a comma appended. This indicates that controls are rendered multiple times according to: http://www.componentart.com/community/forums/t/60999.aspx

I'm sure that both issues are related. The whole dialog with all its controls will be recreated in every asynchronous postback, hence all control names exist multiple times in the DOM(causing the ViewState comma-appending issue). The controls are only visible in FireBug/IE Deveoper Toolbar and not in HTML-Source, hence i assume that jQuery causes these problems. How can i dispose the dialog or how can i prevent the recreation(check if already exists) of the dialog? Is this because the dialog is inside an UpdatePanel or because it's moved(via Javascript) outside the UpdatePanel?

Destroying the dialog before async postback doesn't solve the problem because the dialog will simply disappear:

<asp:Button ID="BtnApplyFilter" OnClientClick="$('#Dialog_ChargeFilter').dialog('destroy');" ... />

Your help is greatly appreciated.

---

Solution: i ended with using the ModalPopupExtender from the AjaxControlToolkit. After some small issues its working like a charm with asynchronous postbacks(don't forget to call MPE.Show() in every code-behind function if you want the popup to stay visible). I could add more code if anybody is interested.

Answer 1

I assume that it has something to do with the Dialog not being inside of the UpdatePanel or something similar.

i've also noticed a problem in the postback-values. All TextBoxes if empty or not have a comma appended.

You are indeed correct on both counts. The crux of the problem is that the Script Manager "thinks" it is supposed to update an element which jQuery has actually moved to a different location on the page, thus resulting in multiple copies of the element and the problems you have mentioned.

I've seen this problem using nested UpdatePanels, but it may occur in other scenarios as well.

This is a problem for which the workarounds are messy.

Option 1 - Change the source code for jQuery UI. I did not have any luck with a quick fix; short of rewriting the entire plugin, I couldn't find an easy to have the dialog work correctly without reordering the DOM. Also, with that route, now you "own" the source code because you have modified it.

Option 2 - Adjust the DOM whenever the page is rendered partially to remove the duplicate elements. You can output some additional script to cleanup the spurious duplicate element. I don't like this approach because it allows the DOM to be in an invalid state until the script runs.

Option 3 - Manually override the rendering of the UpdatePanel. Code looks something like this:

private bool _hasDomPresence
{
    get
    {
        return ViewState["__hasDomPresence"] == null ? false : (bool)ViewState["__hasDomPresence"];
    }
    set
    {
        ViewState["__hasDomPresence"] = value;
    }
}

protected override void OnLoad( EventArgs e )
{
    if( !ScriptManager.GetCurrent( this.Page ).IsInAsyncPostBack )
    {
         // a full postback means we no longer have a DOM presence
         _hasDomPresence = false;
    }

    base.OnLoad( e );
}

protected virtual void ShowDetailDialog()
{
    // code to show the offending dialog

    // we are showing it, so note the fact that it now has a DOM presence
    _hasDomPresence = true;
}  

protected override void Render( HtmlTextWriter writer )
{
    foreach( Control c in this.Controls )
    {
        //
        // find the offending control's parent container prior to it being rendered
        // In my scenario, the parent control is just a server-side DIV
        if( c == this.DetailDialog )
        {
            //
            // here, I am checking whether or not the panel actually needs to be
            // rendered. If not, I set it to invisible, thus keeping a new DOM
            // element from being created.
            if( !this.DetailUpdatePanel.IsInPartialRendering && _hasDomPresence )
            {
                this.DetailUpdatePanel.Visible = false;
            }
        }
    }

    base.Render( writer );
}

This also will confuse event validation because the client and server versions of the page don't match (or at least ASP.Net can't tell that they do). The only way I could find to make this work was to turn off event validation.

With a proper security model, event validation isn't 100% necessary but I don't like being forced to turn it off.

In summary, this is the most evil code I've posted on SO and fluffy white kittens will die if you use it, but the approach does seem to work.

Hope this helps.