The user submits repeatedly in the project. To prevent this, the most common method is to set this button to unavailable after the user clicks the button, I have encountered many different situations in actual development. Here is a summary for your reference.
The first case is a non-submit button.
In this case, you only need to add events on the client and set the button to unavailable. See the following code:
ASP. NET-Code:
<Form id = "form1" runat = "server"> <asp: Label ID = "lbl" runat = "server"> </asp: Label> <asp: button ID = "btn" runat = "server" Text = "Test" OnClick = "btn_Click" OnClientClick = "this. disabled = true "UseSubmitBehavior =" false "/> </form>
C #-Code:
Protected void btn_Click (object sender, EventArgs e) {System. Threading. Thread. Sleep (1000); lbl. Text = DateTime. Now. ToString ();}
The second case is the button of the submit type.
In this case, the first method does not work, and the button cannot be submitted after it is set to DISABLED. We can modify the code as appropriate:
ASP. NET-Code:
<Form id = "form1" runat = "server"> <asp: Label ID = "lbl" runat = "server"> </asp: Label> <asp: button ID = "btn" runat = "server" Text = "Test" OnClick = "btn_Click"/> </form>
C #-Code:
Protected void Page_Load (object sender, EventArgs e) {if (! Page. IsPostBack) {btn. OnClientClick = "this. disabled = true;" + GetPostBackEventReference (btn );}}
Different from the first method, we add a client event to the button in Page_Load and append GetPostBackEventReference. But there is still a trap in this case. After the first request is sent back, clicking the button will fail, so we need to remove if (! Page. IsPostBack), that is, the client events must be repeatedly bound to each sending request.
The third case is similar to the first case, but an UpdatePanel is added.
ASP. NET-Code:
<Asp: UpdatePanel ID = "up1" runat = "server"> <ContentTemplate> <asp: Label ID = "lbl" runat = "server"> </asp: label> <asp: Button ID = "btn" runat = "server" Text = "Test" OnClick = "btn_Click" OnClientClick = "this. disabled = true; "UseSubmitBehavior =" false "/> </ContentTemplate> </asp: UpdatePanel>
The fourth case is in UpdatePanel, but like the second case, it is also a button of the Submit type.
Different from the second case, we only need to bind the client event when loading for the first time, that is, in if (! Page. IsPostBack.
The fifth and fourth types are different. The button is outside the UpdatePanel and the trigger is used to refresh the specified UpdatePanel.
If you follow the fourth method, you can click the button and set it to unavailable, but the button will not be available after sending back:
ASP. NET-Code:
<Asp: UpdatePanel ID = "up1" runat = "server"> <ContentTemplate> <asp: Label ID = "lbl" runat = "server"> </asp: label> </ContentTemplate> <Triggers> <asp: AsyncPostBackTrigger ControlID = "btn" EventName = "Click"/> </Triggers> </asp: UpdatePanel> <asp: button ID = "btn" runat = "server" Text = "Test" OnClick = "btn_Click"/>
C #-Code:
Protected void Page_Load (object sender, EventArgs e) {if (! Page. isPostBack) {btn. onClientClick = "this. disabled = true; "+ GetPostBackEventReference (btn) ;}} protected void btn_Click (object sender, EventArgs e) {System. threading. thread. sleep (1000); lbl. text = DateTime. now. toString ();}
To solve this problem, the simplest way is to put the button in another UpdatePanel so that the original state can be restored every time. In addition, you can explicitly set the button to available after submission based on the page cycle of Atlas.