PowerShell and GUIDs

Interdum at. Eget habitasse elementum est, ipsum purus pede porttitor class, ut adipiscing, aliquet sed auctor, imperdiet arcu aliquam maecenas ligula nostra tempor fermentum. Ligula suspendisse nulla pretium, rhoncus tempor placerat. Lorem ipsum dolor sit amet, ligula suspendisse nulla pretium, rhoncus tempor placerat fermentum, enim integer ad vestibulum volutpat. Nisl rhoncus turpis est, vel elit, congue wisi enim nunc ultricies sit, magna tincidunt. Maecenas aliquam maecenas ligula nostra, accumsan taciti.

Sociis mauris in integer, a dolor netus non dui aliquet, sagittis felis sodales, dolor sociis mauris, vel eu libero cras. Interdum at. Eget habitasse elementum est, ipsum purus pede porttitor. Interdum at. Eget habitasse elementum est, ipsum purus pede porttitor class, ut adipiscing, aliquet sed auctor, imperdiet arcu aliquam maecenas ligula nostra tempor fermentum. Ligula suspendisse nulla pretium, rhoncus tempor placerat.

Lorem ipsum dolor sit amet, ligula suspendisse nulla pretium, rhoncus tempor placerat fermentum, enim integer ad vestibulum volutpat. Nisl rhoncus turpis est, vel elit, congue wisi enim nunc ultricies sit, magna tincidunt. Maecenas aliquam maecenas ligula nostra, accumsan taciti. Sociis mauris in integer, a dolor netus non dui aliquet, sagittis felis sodales, dolor sociis mauris, vel eu libero cras. Interdum at. Eget habitasse elementum est, ipsum purus pede porttitor. Interdum at. Eget habitasse elementum est, ipsum purus pede porttitor class, ut adipiscing, aliquet sed auctor, imperdiet arcu aliquam maecenas ligula nostra tempor fermentum. Ligula suspendisse nulla pretium, rhoncus tempor placerat. Lorem ipsum dolor sit amet, ligula suspendisse nulla pretium, rhoncus tempor placerat fermentum, enim integer ad vestibulum volutpat. Nisl rhoncus turpis est, vel elit, congue wisi enim nunc ultricies sit, magna tincidunt. Maecenas aliquam maecenas ligula nostra, accumsan taciti. Sociis mauris in integer, a dolor netus non dui aliquet, sagittis felis sodales, dolor sociis mauris, vel eu libero cras. Interdum at. Eget habitasse elementum est, ipsum purus pede porttitor.

More on multiple elements per ASP.NET Web Form

2013w06-WebFormPlurality-bothServerCode

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.

2013w06-WebFormPlurality-shot2

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:

2013w06-WebFormPlurality-bothServerOneVisibleCode

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

2013w06-WebFormPlurality-bothServerOneVisibleFirst

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.

2013w06-WebFormPlurality-bothServerOneVisibleCode1

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).

2013w06-WebFormPlurality-bothServerOneVisibleSecond

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

2013w06-WebFormPlurality-bothServerOneVisibleCode2

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

2013w06-WebFormPlurality-bothServerOneVisibleCode3

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.

2013w06-WebFormPlurality-bothServerOneVisibleCode4

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.

2013w06-WebFormPlurality-bothServerOneVisibleCode5

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.

2013w06-WebFormPlurality-bothServerOneVisibleCode6

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?

ASP.NET: A page can have only one server-side Form tag

2013w06-WebFormPlurality-bothServerErrorSmall

A student in a Microsoft ASP.NET web development class recently asked the following question:

 I have a Perl webpage that has multiple forms on it, like this:

<body>
    <form id=forma1></form>
    <form id=form2></form>
</body>

I have tried to do the same thing in ASP.NET and C# with the runat=”server” attribute in the forms, and cannot get it to run.

That’s an excellent question. There is bad news and good news; first, the bad. Unfortunately, ASP.NET “owns” the form so that only one *VISIBLE* server-side form can be on any one .aspx file’s Web Form at a time.

Luckily, there are several workarounds or solutions which might give you what you want.

(1) Here is an article <http://blogs.msdn.com/b/kaevans/archive/2005/10/19/482778.aspx> by Kirk Evans titled “Neat ASP.NET Trick: Multiple Forms on a Page”. There are many references at other web sites as well which convey the fact that you can’t have more than one HTML <form> with the runat=”server” on the same page, however Kirk Evans presents an example where you could Switch Between Two Forms, as opposed to some other authors who simply say it is impossible.

(2) You could have one ASP.NET <form id=”form1″ runat=”server”></form> and another one or more without the runat=”server” such as <form id=”form2″></form>, however you can’t effectively have ASP.NET elements which are processed on the server-side in the second or subsequent forms. It depends on your needs and what you wanted to do with those forms with respect to client-side and server-side processing as to whether that solution is viable.

(3) You could use User Controls with .ascx files and have more than one of them composed on the same ASP.NET Web Form (.aspx file). This technique is pretty straight forward, and is one of my preferred methods for solving this sort of problem.

(4) You could use multiple buttons which act as submit buttons for different sets of controls/fields on the same form, but the C# (or other) code behind the markup treats the fields in distinct sets so that it is almost like having two forms.

(5) You could use update panels with ASP.NET AJAX.

I hope that helps. To all you in the blogosphere, do these options make sense?

Thanks,
++brad;

Back to Blogging

noteGlyph i15

 

Greetings!

It has been a while since I have written any entries in this blog. My February resolution is to share some of the thoughts and questions which have come my way over the interim, as well as new questions from students, customers, and people I come across out in the world.

I hope that you enjoy the rebirth of this blog!

Thanks,

++brad;