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.

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

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.

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 !