ASP.NET中ListView内Button点击后消失问题（UseSubmitBehavior=false）

Let's break down why your btnWishlist is vanishing after the login ModalPopup closes (whether the user logs in or cancels) and how to get it behaving normally without a full page refresh. I’ve tackled similar UpdatePanel/ViewState quirks before, so here’s what’s going on and the fixes to try:

What’s Likely Causing the Issue #

While UseSubmitBehavior=false might feel like the culprit, the real problem is almost certainly related to partial page update (UpdatePanel) state loss. When the ModalPopup triggers an async postback (for login/cancel), the nested UpdatePanel containing btnWishlist isn’t being refreshed to re-render the button. Since the page doesn’t reload, the button’s state isn’t restored unless explicitly handled.

Step-by-Step Fixes #

1. Add Async Triggers to the Button’s UpdatePanel #

Your inner UpdatePanel around btnWishlist doesn’t have any triggers tied to the ModalPopup’s buttons. That means when the login/cancel buttons fire a postback, this UpdatePanel never updates—leaving the button in a broken state.

Update your inner UpdatePanel like this:

<asp:UpdatePanel runat="server">
    <ContentTemplate>
        <asp:Button ID="btnWhishlist" Text='<%# Eval("colbtnwishlist") %>' runat="server" 
            CssClass="wishlistButton" CommandName="btnWhishlist" 
            CommandArgument='<%# Eval("ID") %>' UseSubmitBehavior="false" 
            EnableViewState="true" />
    </ContentTemplate>
    <Triggers>
        <!-- Replace with your actual ModalPopup login/cancel button IDs -->
        <asp:AsyncPostBackTrigger ControlID="btnModalLogin" EventName="Click" />
        <asp:AsyncPostBackTrigger ControlID="btnModalCancel" EventName="Click" />
    </Triggers>
</asp:UpdatePanel>

This tells the UpdatePanel to refresh whenever those ModalPopup buttons are clicked, ensuring btnWishlist gets re-rendered properly.

2. Re-Set Button State in ItemCreated #

Even with EnableViewState="true", async postbacks can cause the button’s text/visibility to reset if the ListView’s ItemCreated event isn’t re-running the logic to set its state. Double-check your usrListShowImages_ItemCreated method to make sure it re-populates the button’s text on every postback:

protected void usrListShowImages_ItemCreated(object sender, ListViewItemEventArgs e)
{
    if (e.Item.ItemType == ListViewItemType.DataItem)
    {
        Button btnWhishlist = e.Item.FindControl("btnWhishlist") as Button;
        if (btnWhishlist != null)
        {
            // Re-fetch the button text from your data source or ViewState
            var itemData = (YourDataModel)e.Item.DataItem;
            btnWhishlist.Text = itemData.colbtnwishlist;
            // Ensure the button is visible (in case it got hidden during postback)
            btnWhishlist.Visible = true;
        }
    }
}

This guarantees the button’s state is re-established every time the ListView item is recreated, even during async postbacks.

3. Simplify Nested UpdatePanels #

Nested UpdatePanels can cause unexpected state conflicts, especially when the outer panel (up_inlv) has UpdateMode="Conditional". Try removing the inner UpdatePanel around btnWishlist and moving the triggers to the outer up_inlv instead:

<asp:UpdatePanel runat="server" UpdateMode="Conditional" ChildrenAsTriggers="false" ID="up_inlv">
    <ContentTemplate>
        <!-- ... your existing markup ... -->
        <asp:Button ID="btnWhishlist" ... /> <!-- No inner UpdatePanel anymore -->
        <!-- ... rest of your content ... -->
    </ContentTemplate>
    <Triggers>
        <asp:AsyncPostBackTrigger ControlID="btnModalLogin" EventName="Click" />
        <asp:AsyncPostBackTrigger ControlID="btnModalCancel" EventName="Click" />
        <!-- Keep any existing triggers for btnWhishlist/btnCart -->
        <asp:AsyncPostBackTrigger ControlID="btnWhishlist" EventName="Click" />
    </Triggers>
</asp:UpdatePanel>

Fewer nested panels mean fewer opportunities for state to get lost during partial updates.

4. Force Button Visibility with JavaScript (Fallback) #

If the above fixes don’t work, you can explicitly force the button to show after the ModalPopup closes. Add this client-side script to your page:

// Wait for the page to load
$(document).ready(function() {
    // Get reference to the ModalPopupExtender
    var modalPopup = $find('<%= mpeLogin.ClientID %>');
    // Add a closed event handler
    modalPopup.add_closed(function() {
        // Show all wishlist buttons using their CSS class
        $('.wishlistButton').show();
    });
});

Or if you prefer server-side, register a startup script after login/cancel:

protected void btnModalLogin_Click(object sender, EventArgs e)
{
    // Your login logic here...
    // Force the button to show after postback
    ScriptManager.RegisterStartupScript(this, GetType(), "ShowWishlistBtn", 
        "$('.wishlistButton').show();", true);
}

Key Takeaway #

The root issue is that your button’s container wasn’t being refreshed during the ModalPopup’s async postback. By tying the UpdatePanel to the ModalPopup’s buttons and ensuring the button’s state is re-set on postback, you’ll get the persistent visibility you want without full page reloads.

内容的提问来源于stack exchange，提问作者user1489440