Asp.net button pitfall

I had just resolved a very ugly bug in one of our screens. The behavior was the following:
You open a the page and click on a “cancel” button that closes the current screen and refresh the parent screen.
So far all is sweet.
Now you do it again (open & click “cancel”)
So far all is sweet.
Try to open any other page.
gosh! nothing works! Everything got stuck somehow…

The cancel button was declared like this:


<asp:Button id=“…” runat=“server” OnClientClick=“RefreshParentAndCloseMe();” />



Can you spot the problematic approach here?
Button.AutoPostBack is set to True as default which means that clicking on the button triggered page submit but at the same
time we run javascript code to close the window. My guess is that the server gets a new request and handles it but the client
is dead until then(until the response is ready).
Playing with this behavior can lead to unexpected behavior (in our case – we had to close the browser and start over)

Solutions?
  A. Use html button (I prefer this one as this pure client behavior button)
  B. change the OnClientClick to: OnClientClick=”RefreshParentAndClose(); return false;”
  C. Set AutoPostBack=False on the button.

 

Dynamic validators and controls hookup in ASP.NET Ajax

In one of our screens, we have a list of items on the left pane and “details” screen on the right pane. The details pane appears only when one of the items is selected. If no item is selected – we show some sort of empty pane that describes the usability of the screen and ask the user to select an item in order to continue.


In order to switch between the details\empty panes, I draw two span elements and played with their visibility property. The controls are partially rendered which means that if the user did not select an item, no “details” controls or rendered and neither their validators. The problem is that ASP.NET register the validators only once (via ValidatorOnLoad() method) and on the first time the screen is rendered, the controls are not there yet (no item is selected by default).


The solution was pretty straight-forward, I think. I’ve downloaded a simple call to my javascript method so the validators will be re-attached again:


ScriptManager.RegisterStartupScript(this, this.GetType(), “HookupManuallyToValidators”, “ReRegisterValidators();”, true);


And the javascript method:


function ReRegisterValidators()
{
   if (typeof(Page_Validators) == “undefined”)
      return;

   var i, val;
   for (i = 0; i < Page_Validators.length; i++) 
   {
        val = Page_Validators[i];
        ValidatorEnable(val, true);
   }
}


1-0 to lnbogen .vs. asp.net

 

Override OnPreInit on a Page with Master Page

I’m doing one of the most complicated UI I’ve ever did(ASP.NET). In the process, I need to generate tabs(via MultiView control) pragmatically and for each tab render a tree-like checkboxes. All based on external xml. Yami.. ;-)


Reading a little about how to add dynamic View to MultiView control made me realize that I need to do my magic on the page’s PreInit event. This one was quite easy, I’ve override the OnPreInit (I could register to the event in the page constructor, but this is easier) and called my dark voodoo “BuildTabs” method. All is good.


Now, Adding MasterPage to the blend made me puzzled for a few minutes. It seems that the page’s controls are not initialized on the PreInit phase if the page has MasterPage. After I got my eyes back on the screen, stop nodding with disappointment and taking my head off the wall, I used my built-in behavioral program:


pre-think (short phase ~Thread.Sleep(1000*60));
while(no solution yet) { 
   try;
   think;
}.


2 minutes later I found the trick:


protected override void OnPreInit(EventArgs e)
{
   base.OnPreInit(e);
   base.Master.Init += new EventHandler(Master_Init);
}

void Master_Init(object sender, EventArgs e)
{
   BuildTabs(); //we must draw it from scratch on each post-back.
}


Now the controls are initialized and I can program in peace.

 

Changing the Output Path in your Web Applications is a bad idea

<rational thinking>


Let’s assume we have a WebSite(the same issue applied to WebService btw) named WebApplication1. Now, we want to put its(the website’s) output files into some other directory (!= “bin” directory) for development reasons (working as part of a team with some sophisticated Source Safe). What’s the first thing you (and me) do? we use our “rational” programmer nature and Right-Click on the project->Properties->Build Tab->and changing the Output path to whatever we need.


OutputPath.gif


(Instead of “bin\” we can write here “..\..\infrastructure” for example)



We then build the all thing and surprise surprise, the new output path contains all the dlls as expected. Awesome!
Satisfied with the greatness of Visual Studio .Net 2005, we now want to Publish the WebSite so we(or the QA) can play with it. “Think as a developer, think as a developer” I say to myself and Right-Click the WebSite project->Publish… A few really easy “decisions” and ~10 seconds later, VS.NET tells(it speaks to me, I swear) me that my site was published successfully.


Happy as a little girl with a new puppy, I enter my site: http://localhost/webapp1/Default.aspx and Oops!


OutputPathUnableToFindClass.gif


The page can’t find its “code behind”(The class that it inherits from)! What the hack is going on here!?


Well, it turns out that the Publish process is not as smart as you may think it should be. Changing our Output path to another directory (!= “bin”) caused this all mess as the Publish process simply copy all the files from the bin directory into the new(Published) bin directory. No questions asked. The Publish algorithm do not check if you actually compile your dlls into another directory via Output path and taking it into account.


</rational thinking>


<effective thinking>


Fortunately for us, the solution is pretty easy: define your Output path into the original location (“bin\”) and use the Build Events(post-build in this scenario) in order to copy the output files into your “infrastructure”(or whatever) directory like this:


OutputPathUsePostBuild.gif


(The command: xcopy /Y /S ${TargetDir}*.* ..\..\Infrastructure)


</effective thinking>



May it save you the 15 minutes it took me and my teammate Hagay to solve this one.

 

Script# – Write JavaScript via C#

Nikhil Kothari, one of the coolest programmers on the planet (and one of the folks behind Atlas) came up with a brand new compiler which will basically allow you to write JavaScript via C#.
He named it Script# (pronounced: ScriptSharp).


This means you can now write JavaScript equivalent code with full IntelliSense, compile time error checking and full debugging enabled framework !!


Let me repeat (I’m hooked, sorry ;-)):


(1) No more need for alert(“…”) or debugger;
(2) You can compile the code and get typos errors before running the explorer and be spammed with yellow message boxes.
(3) IntelliSense people. IntelliSense. no need to open MSDN to find window or document members.
(4) I hate prototyping in JavaScript – The syntax is quite confusing and I’m lacking 2 must-have IDE features: “Go To Definition” and “Go To Reference”. Now you can do it all via C#.


The idea is pretty simple. You, the developer, write C# code and compile it. Behind the scene, the Script# compiler transforms your C# code into equivalent JavaScript and create a *.js file automatically for you. This (js)file will be download to the client (you can even use the new WebResource Attribute in ASP.NET 2.0) and that’s it.


You can find a set of demos, examples and of course -the binaries at Nikhil’s Blog.


Fantastic !