More on multiple elements per ASP.NET Web Form


I recently wrote a note about several possible solutions to simulating multiple web forms on the same page when using ASP.NET Web Forms, to work around the restriction of one active (visible) ASP.NET <form> per .aspx page. Although a good article by Kirk Evans titled “Neat ASP.NET Trick: Multiple Forms on a Page” shows the technique, I wanted to elaborate with some more step-wise details.

First, what I had described earlier as option #2, is shown in the listing at the top of this page. Note that the <form id=”form2”> has only classic HTML <input> items used literally. Although these are the exact kinds of elements that ASP.NET will generate in the rendering phase for “form1” in that example, ASP.NET does not allow multiple server-side forms on the same Web Form (i.e. .aspx file). This yields the following visual result, which unfortunately does not functionally do what the button text implies.


Rather than focusing on making that functional via JavaScript or other techniques, let us focus on what I had described as option #1 in the earlier blog post, with a step-wise approach.

Although having two or more <form> elements on the same ASP.NET Web Form throws an exception if two or more server-side <form> elements are visible, as Evans had pointed out, we can make all but one of those forms invisible as follows:


This results in only the first form being visible, but it loads without the exception.


If you add behavior to the button to switch the visibility of both forms, then you can switch from form1 to form2 at the press of a button.


Of course, in a real form, you would likely have logic to process the information from the form, however only the visibility switching code is shown here for clarity. Pressing the button makes form1 disappear and form2 magically appears (it isn’t really magic, it’s just the changing in the rendering based on those two form1.Visible and form2.Visible properties above).


You could add exactly the reverse action into the Button2_Click event handler wired up to this button as follows:


The WebPlurality.aspx markup shows the onclick wiring of the event handlers to these events for the appropriate buttons.


Now, the user of the web form can switch from form1 to form2 and back as many times as are necessary to the same URL for the WebFormPlurality.aspx and they alternate between the two ASP.NET server-side forms. Certainly, other events besides buttons firing could be used to trigger the alternation between the forms.

Perhaps you are wondering what benefits are afforded by sharing the same .aspx file (ASP.NET Web Form) for two forms. Consider that the view state and use of one Page class is used. Although different instances of that class may be used for each postback, however having the same class code loaded into the web host has its benefits. But the benefits of sharing the same view state for two or more forms within the same ASP.NET Web Form has many implications for JavaScript scripting and AJAX interactions as well, not just better continuity for processing postbacks. The topic of benefits of doing this deserves its own topic. Let me know if you’re interested in more details. For now, let’s get back to the mechanics of switching between web forms sharing the same .aspx file.

Again, there are many ways in which the switching between the forms could be accomplished. One technique shown thus far is to have the onclick event handlers for the buttons do the visibility switcheroo of the forms. One of the possible alternatives is to have the Page_Load method switch them, as Mr. Evans’ article had suggested. The result would resemble the listing below.


As written, this code will switch between two forms, where one had been visible previous and the other not visible, it simply inverts the visible of each. For three or more forms this would need to be modified with some sort of signal, request or pecking order, thus the button-driven approach can have its advantages for three or more forms. One problem with this Page_Load visibility swap technique even for two forms. Because form1 was initially visible and form2 was not, this Page_Load method implementation depicted above actually shows form2 first, then allows switching to form1, which might not be what had been intended by the designer who had set up form1 to be visible in the .aspx markup. Luckily, there is a simple fix for that feature.


Before discussing that fix, let’s clean up the code by removing the Button1_Click and Button2_Click methods, and then scrubbing the wiring of the onclick= attribute to those from each of the buttons in the markup. The above version of the WebFormPlurality.aspx shows this. Now, on to that other fix with the Page_Load method.


Note that the above version of WebFormPlurality.aspx.cs has an if( IsPostBack ) clause with the body being the swapping of the visibility. This accomplishes the goal of retaining the states of the visibility set in the .aspx markup file upon initial load, and inverts only on postbacks, whether they are caused by button actions or other events which trigger postbacks to the page.

As in Mr. Evans’ example, the last two listings would be sufficient to illustrate that the visibility can be swapped between two <form runat=”server”> elements on the same .aspx Web Form. However, the sequence shown in this article has given us the opportunity to mention some of the other possible ways of implementing something similar as well as hint at some of the ramifications and related tangential possibilities. What might you use such a technique for? Or what have you used such a technique to accomplish already?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.