rousso.eu » ASP.NET

Multiple calls to RegisterOnSubmitStatement and Client-Side Validation

rousso — Sat, 02 Dec 2006 08:54:00 +0000

Ok! Here is a new thing I discovered yet again the hard way…

In short: Do not call Page.ClientScript.RegisterOnSubmitStatement after the Page Load event.

(What?!)

Well yes! It’s not under all circumstances that you can notice the difference but it’s there and it’s major!

I do not really wan to describe this, so I ‘ll take you though it with an example:

Let’s say you have an aspx page. The page has two controls in it. For simplicity lets make those controls UserControls. The controls are pretty simple: just a TextBox and a RequiredFieldValidator in each of them.

So there you have it:

Control A (let’s call it OnSubmitControlA):

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="OnSubmitControlA.ascx.cs" Inherits="OnSubmitControlA" %>

and the code file:

public partial class OnSubmitControlA : System.Web.UI.UserControl
{
   protected override void OnPreRender(EventArgs e)
   {
      Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomething", "alert('This alert is registered by OnSubmitControlA');");
      base.OnPreRender(e);
   }
}

Control B (let’s call it OnSubmitControlB):

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="OnSubmitControlB.ascx.cs" Inherits="OnSubmitControlB" %>

and the code file:

public partial class OnSubmitControlB : System.Web.UI.UserControl
{
   protected override void OnPreRender(EventArgs e)
   {
      Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomethingElse", "alert('This alert is registered by OnSubmitControlB');");
      base.OnPreRender(e);
   }
}

And finally the page itself:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="OnSubmitTest.aspx.cs" Inherits="OnSubmitTest" %>
<%@ Register Src="OnSubmitControlA.ascx" TagName="OnSubmitControlA" TagPrefix="uc1" %>
<%@ Register Src="OnSubmitControlB.ascx" TagName="OnSubmitControlB" TagPrefix="uc2" %>

   
      Test Page

(the codefile has nothing special in it…)

The page has of course a submit button so that we can submit and test it…

So! What we have here!?

A Page,
two controls that wan to access client-side code just before the page submits (for no particular reason)
and at least a Validator Control that will fail validation at some point. (If we did not have a validator then I would not have a case here!)

Now go render the page an see the result. If you leave either TextBox empty and click on the submit button, you will notice that only the alert from the first control pop’s up. The other registered script is never called….

Now go back and make a slight change. Move in both contols’ codefile the call to Page.ClientScript.RegisterOnSubmitStatement from OnPreRender to OnLoad, like this:

public partial class OnSubmitControlA : System.Web.UI.UserControl
{
   protected override void OnLoad(EventArgs e)
   {
      base.OnLoad(e);
      Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomething", "alert('This alert is registered by OnSubmitControlA');");
   }
   protected override void OnPreRender(EventArgs e)
   {
      // Let's comment this out
      // Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomething", "alert('This alert is registered by OnSubmitControlA');");
      base.OnPreRender(e);
   }
}

do the same on the other control:

public partial class OnSubmitControlB : System.Web.UI.UserControl
{
   protected override void OnLoad(EventArgs e)
   {
      base.OnLoad(e);
      Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomethingElse", "alert('This alert is registered by OnSubmitControlB');");
   }
   protected override void OnPreRender(EventArgs e)
   {
      // Let's comment this out also
      // Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomethingElse", "alert('This alert is registered by OnSubmitControlB');");
      base.OnPreRender(e);
   }
}

Done! Go back and render the page! Leave either TextBox empty and click submit… See??? Now both alerts pop up!!!

Why is that???

Well look at the source of the rendered page before and after the change to see what’ going on:

Here is the script rendered when the call to RegisterOnSubmitStatement is placed in the OnPreRender event:

And here is the script rendered when the call to RegisterOnSubmitStatement is placed in the OnLoad event:

Got it?

If RegisterOnSubmitStatement is called after OnLoad, then the first time it’s called the framework appends the statement that calls ValidatorOnSubmit() and returns false if it fails; (effectively blocking the rest of the script from executing). Subsequent calls of RegisterOnSubmitStatement (after OnLoad) are appended to the script generated by the first call (and get blocked by the effect I just described).

Instead, if all your calls to RegisterOnSubmitStatement come before the end of the OnLoad phase, then all registered scripts are appended to previously generated scripts before the eventual injection of the call to ValidatorOnSubmit().

Hoping for comments on this…

UseSubmitBehavior & GetPostBackEventReference

rousso — Mon, 29 May 2006 08:00:00 +0000

funny thing…

I needed a button (in an ASP.NET 2.0 page) to post-back and raise an event for another control. That means that I click a button but the post-back event is not handled by the button clicked but instead by another control on the same page.

The easy way was to add a System.Web.UI.WebControls.Hyperlink and set its NavigateUrl property to Page.ClientScript.GetPostBackClientHyperlink(myOtherControl, "Arguments")

But I wanted it to look like a Button so instead I added a System.Web.UI.HTMLControls.HTMLButton Control and did the same thing to its OnClientClick property.

All worked fine.

The funny thing happened when I decided that I like most to use a System.Web.UI.WebControls.Button instead.

ASP.NET Buttons are rendered as ="submit" /> controls. and by default their client-side onClick event is wired to the __doPostBack javascript method by ASP.NET.

To change that behavior in ASP.NET 2.0 we are supposed to use the UseSubmitBehavior Property which when set to false causes the Button to be rendered as "button" /> and allows you to set the client-side onClick event programmatically (or declaratively) by setting the OnClientClick server-side Property.

That’s what I did, only to discover that to whatever I was assigning to the OnClientClick Property, the original __doPostBack call was automatically appended by the framework.

I did not spend all the time in the world to figure this out and as I failed to find a reasonable way out of the problem, what I did, was to trick the client-side out of it by appending a JavaScript “return;” statement to the script I was assigning to OnClicntClick.

To make all these more obvious here is the hands on:

in the aspx/ascx file:

...

Notice that lines 5 and 6 above define the Hyperlink and HTMLButton that worked fine and line 7 defines the WebControls.Button that did not behave. Lines 1 to 3 define a DetailsView just because that is the control I wanted to handle the post-back event.

Now in the code file:

HyperLink1.NavigateUrl = Page.ClientScript.GetPostBackClientHyperlink(DetailsView1, "New$0", true);
Button1.Attributes.Add("onClick", Page.ClientScript.GetPostBackClientHyperlink(DetailsView1, "New$0", true));
Button2.UseSubmitBehavior = false;
Button2.OnClientClick = Page.ClientScript.GetPostBackEventReference(DetailsView1, "New$0");

These get rendered as follows at run-time (if you look at the source in the browser):

HyperLink

This works just fine if you click on the Hyperlink1 or Button1 controls, but not at all if you clicked at Button2. That is because Button2 makes the call to __doPostBack twice. Once because I asked it to do so (by assigning its OnClientClick Property as you see in line 4 of the code-file above) and once because the framework automatically inserted the default post-back event reference for the button (Button2) itself.

To overcome this behavior (as I could not find another way around it) I just changed the last line in the code-file (line 4 in the snippet) by appending a javascript return statement as follows:

Button2.OnClientClick = Page.ClientScript.GetPostBackEventReference(DetailsView1, "New$0") + "; return;";

This caused Button2 to render as follows:

Notice the return statement (in bold) rendered between the two calls to __doPostBack. Although this does not prevent the second __doPostBack call from beeing inserted by the framework, it does prevent it from executing….

If you know a proper way out of this little puzzle please let me know….

P.S:

As you obviously noticed I needed the button to create an Insert button that would enable a DetailsView to go to Insert Mode even if the view has no items to display. The button (when clicked) causes the DetailsView to receive an Insert Command.
Of course you fortunately do not need to do all this to make a details view to enter Insert Mode. It would be enough to just and any button with a server-side Click event handler changing the mode to Insert by just calling DetailsView1.ChangeMode(DetailsViewModes.Insert);

ASP.NET 2.0 Experiences

rousso — Wed, 23 Nov 2005 09:03:00 +0000

With this post I am opening a series -hopefully- of posts, based on my experiences with ASP.NET 2.0. This post by itself is at the moment incomplete.

I have been programming ASP.NET since version 1.0 and did most of my work in ASP.NET 1.1. Only recently, and just after the release of Visual Studio 2005 and the .Net Framework 2.0 I started working in ASP.NET 2.0. I have two initial goals to accomplish (apart from learning all the new and changed features of the new release):

I want to port my version 1.1 code libraries to ASP.NET 2.0
I want to create a web project I had in mind for the last couple of months in ASP.NET 2.0

In the future I will probably work in ASP.NET 2.0 exclusively and I also might want to port some of my version 1.1 apps to version 2.0.

My first findings so far:

ASP.NET 2.0 includes a framework for web site membership, role based security, and personalization. It is based on the same authentication and authorization mechanisms that come from version 1.1 but introduces the use of a data store and a “provider” API to support the new features. Previously I used to use my own implementation of such features using a custom solution. The new version makes my relevant code somewhat obsolete. I am already trying membership, roles and profiles and finding them easy and helpful. I ‘ll get back to you with more specifics on this…

…to be continued…

My Funny Surprises With .NET 2.0

rousso — Fri, 18 Nov 2005 09:05:00 +0000

As I was developing applications for .Net Framework 1.0 and 1.1, I was building a couple of code libraries with features I found smart and useful for my apps.

Being an active member of dotNetZone.gr, (a Greek .net developer community often nicknamed DNZ), I recently decided to share some of that code with others in DNZ.

The idea was to do that while porting the code to .Net Framework 2.0 through Visual Studio 2005.

Now, what’s so funny about that?

First thing I wanted to share was my Wizard classes. I implemented them in the context of a web project and used to find them brilliant.

Using SourceSafe Ι started today pinning and branching code to a new VS 2005 solution that would contain the part of my libraries related to Wizards.

“Come on! Where is the funny part?” you would still ask!

Well I compiled it and got the following compile time errors:

Error1: ‘Wizard’ is an ambiguous reference between ‘System.Web.UI.WebControls.Wizard’ and ‘Softbone.Shared.Wizards.Wizard’
Error 2: ’WizardStep’ is an ambiguous reference between ‘System.Web.UI.WebControls.WizardStep’ and ‘Softbone.Shared.Wizards.WizardStep’
Error 3 ’WizardStepCollection’ is an ambiguous reference between ‘System.Web.UI.WebControls.WizardStepCollection’ and ‘Softbone.Shared.Wizards.WizardStepCollection’

(note: Softbone is brand name I am using, and Softbone.Shared is the namespace of the shared code library I am creating porting my code from .net framework 1.1 to 2.0).

Ooops!

Not only Microsoft implemented the same functionality as I did, but the just happened to have chosen the same class names as I did!

Well that, I thought was funny enough to mention…

So, it might be the case that my library is obsolete with the new version of the .Net Framework, but still, here is what is more interesting about it now than ever: I have to check my implementation against Microsoft’s one to see where mine falls short or even if I did some things that are better or smarter than Microsoft’s.

So I will be posting my code soon to my main blog and my .net blog in DNZ and keep you posted here, to see if I have more interesting or funny encounters during my Wizard Library porting to .Net Framework 2.0.

I ‘ll let you know….

VS.NET Copy Project

rousso — Thu, 14 Jul 2005 08:22:00 +0000

Here is a solution for an issue I run into today.

Issue:

In VS.NET 2003 I tried to use the "Copy Project" feature to copy (deploy) the files required to run a web application to another web server. Nevertheless I got an error saying (more or less): …"error occurred while copying the project" … "Visual Studio .NET has detected that the specified Web server is not running ASP.NET version 1.1. You will be unable to run ASP.NET Web applications or services".

Context:

I was evaluating Community Server 1.1 and I had a full source installation on my Windows XP workstation altering bits and pieces to customize the application. I had previously installed a binary installation of the same product to my Windows 2003 Web Server.

Reactions:

First I made sure ASP.NET was running on my remote web server. Just to be on the safe side I even run aspnet_regiis -i, but it did not fix the problem. I had never encountered an issue like that so I googled for it. I found similar problems but all had solutions I had already tried with no luck. So mine had to be different.

Solution:

I figured out what was wrong when I tried to find out what my VS.NET was doing on my workstation to determine the ASP.NET version on my remote web server. It turned out that VS.NET did an HTTP request to:

http://MyRemoteWebSrver/MyApplication/get_aspx_ver.aspx

This file (an actual ASPX page named get_aspx_ver.aspx) does not exist so the server returns the well known "resource not found" error page. But ASP.NET in that default error page, returns the .NET Framework version information which is in turn used by VS.NET to verify version information. Silly but true!

Now! The problem was that Community Server by default had defined Custom Error Pages. So suddenly it occurred to me and here is what I did to solve the problem:

I went to my remote web server, and added the following lines to the web.config of my application:

Solved!

P.S: I also added the same lines to the web.config in my workstation since I was about to overwrite the web.config on the server. Remember I was originally trying to copy the files needed to run the project from my workstation to the web server using Copy Project feature of VS.NET.