original haXX

Since all my recent web coding has been in ASP.NET 2.0 (at a minimum), I’ve been using the server-side controls almost exclusively. This means that almost all of the controls on a page are using the new ASP.NET syntax.

Do you still use a reset button on your web forms? I do, and I do not like the idea of doing a postback just to reset my input controls.

If you’ve coded a reset button on your page using ASP syntax, you’ve undoubtedly coded something like this…

<input type="reset" id="ResetButton" value="Reset">

… to show a button to reset all the input form values to what they originally were when the page was first loaded. With ASP.NET you’ve now realized that there is no type=”reset” for an ASP.NET button. Of course, you can just code it using the old ASP syntax as shown, and it will work fine. But I wanted an all-ASP.NET solution.

What I wanted was the traditional behavior of the reset button that returned my input fields to their original values, and didn’t require a postback (like the ASP.NET button will do).

If you investigate how ASP.NET creates the main form for your page, you’ll see that it always names it aspnetForm. While I can’t be sure this will always remain true, it’s working for me now, and I hope Microsoft doesn’t change it with a maintenance release. Because of that, I have to stress that this suggestion be used at your own risk, and don’t be surprised if something gets broken in a future release of ASP.NET.

I use a JavaScript function on my page that actually performs the reset. I’ll link to this function in the OnClientClick event for my reset button. Here’s what the function looks like.

function ResetChanges() {
   var theForm = document.forms['aspnetForm'];
   if (!theForm) {
      theForm = document.aspnetForm;
   }
   theForm.reset();
   return (false);
}

This is how I’ve coded the actual ASP.NET button to call the ResetChanges() method at runtime, without a callback.

<asp:Button ID="ResetButton" Text="Reset" runat="server" OnClientClick="return ResetChanges();" />

This is working fine for me, and I hope it solves the same issue you may be having, trying to keep your code all ASP.NET. If you have any comments or run in to any troubles, please let me know in the comments sections.

The SignonManager process is used to limit concurrent logons to the website to only one per user.  This will prevent users from starting multiple sessions simultaneously, as could happen if multiple users were sharing a User ID.  The control mechanism is the User ID and the Session ID.  If the user is able to connect a second time with identical credentials, then they will be allowed to continue.  If the Session ID is different, then the original user is considered to be superseded and will be redirected to a ‘forced off’ page on the next server request.

This version of the SignonManager is written in VBScript, and intended to be used in an Active Server Pages (ASP) environment. See my other post for a version of this utility for use in an ASP.NET, C# environment.

Read more…

I have to limit users to a single logon in my web application. This web application uses a custom logon process that validates the user’s credentials, and then stores the User ID and other things in a session object. If a user should log on with the same User ID as an already logged on user, the already logged on user should be terminated.  I also needed to be able to view the list of logged on users.  Your requirements may be a lot different, but this is what I need.

My design approach is based on keeping a list of currently logged on users, and checking this list on every server request. If Session2 logs on with the same User ID as Session1, the next time Session1 requests a page from the application, they will be identified as superseded. Once identified, they will be transferred to a special page indicating the reason for being forced off. My goal is to introduce as little overhead as possible because the code for this process is added to the code length of every request by a logged on user. While trivial in execution, the sheer number of calls will be tremendous and add to the overall server load.

Read more…