Every once in a while while working with ASP.NET there comes a time when you need to have a DropDownList with a fixed set of items. Or maybe the items are retrieved from the database, but still every instance of the control will have exactly the same items. How to do it efficiently?

Lets look at the simple example of a DropDownList with country names - the one you see on many pages. Wouldn't it be nice to have a reusable control for this?

The simplest way to create a Self Populating DropDownList is to inherit from the standard one, set the DataSource somewhere and call DataBind(). That is the tricky part.

If you have been working with ASP.NET for a while you are probably aware of the ViewState thingy. As good as it is, it can often make your page too large. This is specially true for DataBound controls. A simple Counties DropDownList would make your ViewState huge! So what can be done about it? Just disabling ViewState won't help because usually disabling it breaks some of the other parts of control's functionality.

Dealing with ViewState is simple once you get to know one very important thing. Only changes made after the Init phase of the Life Cycle are persisted to the ViewState! Or more precisely, changes only changes made after the control has started tracking ViewState (TrackViewState method has been called). It means that everything you put to the ViewState before that, will not be persisted. By default controls will have their TrackViewState method called right after the Init phase.

We can use this knowledge to our advantage. If we populate our DropDownList before or during the Init phase we will not affect ViewState. Doing so however has one drawback: we have to perform this operation on each request and not only when IsPostBack is false. This is not an issue if we use some kind of cache and we populate a lots of controls with the same data.

Add to del.icio.us

There are a lot of articles on how you can debug you JavaScript code using Visual Studio 2005. There are basically two cases:

1. Debugging ASP.NET pages inside the Visual Studio's solution.
2. Debugging other pages - not included in the solution.

In the second case, all you have to do is attach to a process of a running Internet Explorer using Debug->Attach to Process... menu option, in the first case, all you need is to run the solution in debug mode.

The rest of the scenario is the same for both cases. Visual Studio allows you to open any script document currently loaded into the Internet Explorer process you are currently attached to. This is done via the Script Explorer window which you can turn on using Debug->Windows->Script Explorer menu option or by using the Ctrl + Alt + N keyboard shortcut. The window should look more or less like this:

The problem is that more often than not, debugging JavaScript in Visual Studio simply does not work! I have spent countless hours trying to find the solution or even the cause of this problem, but without success. There are many "solutions" on out there but none of them really solves the problem. Most of them simply don't work! Probably Microsoft fails to acknowledge this as a problem since it has been around for few years now - judging by the news group posts dates.

Add to del.icio.us

There is a bug in Visual Studio 2005 (but I think I have also seen it in Visual Studio 2003) that causes multiple break points to be set in case you have few files with the same name opened using Script Explorer window. (if you are fortunate enough to have it working).

Steps to reproduce the problem are simple. Just ran a simple page with a Textbox and a Button control and some kind of Validation control. This will ensure that the presence of two "WebResource.axd" JavaScript includes: one for with Validation code and the other one - the standard ASP.NET one. Try to set a breakpoint in the first line of any of the script files included. Use Script Explorer window to get the files. Notice that the breakpoint appears in both files. Also sometimes the focus is moved to one of the other files. Imagine having a couple of scripts included in such a way and all those unneeded breakpoints!

As mentioned above, I have noticed this behavior also in Visual Studio 2003, but I have not tracked it down. I'm almost sure however that there was also the same type of problem also with normal files included in the solution. (yet again, I can't remember for sure).

Fortunately removing breakpoints works correctly so you can remove unnecessary breakpoints once they are created.

As a side note. While writing this article my Script Explorer windows stopped working and this also means that script debugging inside Visual Studio also does not currently work, so I'm unable to provide any more details. I hope though that Microsoft will correct this problem sometime in the future.

Add to del.icio.us

Every ASP.NET developer knows (or at least should know) about the Life Cycle. Page has it's Life Cycle, controls have theirs Life Cycle (more or less the same as the one of the Page). There is a good article on MSDN regarding the Page Life Cycle. From it, you will learn that at any given moment, the Page and all controls are in the same "phase" of the Life Cycle, be it Init, Load, PreRender or Unload.

The interesting part about the Life Cycle is when it comes to dynamically added controls. The controls you add in code using Controls.Add call. Since controls also have the Init, Load and PreRender and Unload phases, what happens when we add a new control during a PreRender phase? As stated above, Page and all controls are always in the same phase. So what happens?

The same article explains this phenomenon and calls it "Catch-up". What it basically means is that at the time of adding a control to a Controls collection, the new control "walks" through all it's phases until it "catches-up" with the current phase of it's parent control (i.e. Page).

In order to better understand this, you can use the following example. On your page override an OnPreRender method and add a following code:

protected override void OnPreRender(EventArgs e)
{
    base.OnPreRender(e);
    Button b = new Button();
    b.Load += new EventHandler(b_Load);
    b.Init += new EventHandler(b_Init);
    b.PreRender += new EventHandler(b_PreRender);
    b.Unload += new EventHandler(b_Unload);
    Controls.Add(b);
}

You will also need to create the event handler methods. As the next step, put a break point on each of those handler methods and run the debugger to see what happens. You will notice that when control is added to a collection of Controls, it's events are fired immediately to catch up with the phase of its parent.

Add to del.icio.us

After a while of thinking and struggling with Control Adapters I was unable to find a good solution to get my Validation Controls render as images. I have came to the following conclusions:

1. Control Adapters will not help
2. Overriding each Validator is not a good solution
3. Creating my own Validation Controls is not a good solution

Given the above, I have once again looked at everything I have learned. I have looked at the html code rendered by the controls and then... solution came to me! It turns out that we don't need ASP.NET to get things working. ASP.NET stands in our way when it comes to handling this task, so why not use a plain old CSS? So I did.

When Validaton Control:

<asp:CompareValidator runat="server" ID="V" ControlToValidate="c1" ControlToCompare="c2" Text="Error Text" ToolTip="Title Text"></asp:CompareValidator>

is rendered on a page it looks more or less like this:

<span id="ctl00_V" title="Title Text" style="color:Red;visibility:hidden;">Error Text</span>

To make a nice image out of it, we need few things. First we need one tradeoff: we have to remove the Text attribute, otherwise it will mess the looks a bit. Next we decorate the server control with a CssClass attribute with a value such as "error". Next we create a style:

span.error
{
  display: -moz-inline-stack;
  display: inline-block;
  background-image: url(error.gif);
  background-repeat: no-repeat;
  height: 16px;
  width: 16px;
}

Notice in the style few things. First, we need the <span> element to be "inline-block". That is because we need it to have a height and width. Furthermore, FireFox does not support "inline-block" (!!!) but we can use a simple workaround with "-moz-inline-stack" value as described by Nicholas in Pain with inline-block article (also see the comments). By default span (inline element) will only be as large as the text it contain. Since in the proposed solution, there will be no text in the <span> this is needed. Next, we set the background-image to a desired url and set the width and height of an element. That's it!

The important thing to note here is the "inline-block" value for a display property. It is a CSS 2.1 introduced value and browser support may vary. After analyzing the display declaration article on quirksmode, I've came to a conclusion that it should be safe to use this technique. Internet explorer "supports" it. Firefox "supports" it. Opera supports it.

Yet again. ASP.NET stands in the way... If you try to use a Display="Dynamic" property, you will find that the proposed solution does not work with FireFox. After a close analysis I came to a conclusion that it works with IE only by chance. The problem is that the validation scripts used by Validation Controls set elements display property to "inline" in case Display property was set to Dynamic on the server control. Internet Explorer somehow manages to use the value from the style which is "inline-block" and so it works. FireFox uses the "inline" value and so we have an <span> element with no content - an invisible element.

I have currently few ideas of how to overcome this problem. One way it could be done is to put an absolutely positioned Validation Control inside a relatively positioned <div> element like this. Remove the Display="dynamic" attribute and mark the containing div with a class="error" and change the styles as follow:

div.error
{
  position: relative;
  display: inline;
}
span.error
{
  position: absolute;
  left: 0; top 0;
}

The positioning of elements needs some work, but hey at least it works!

Complete code here: ValidationControlsAsImages.txt (.54 KB)

Add to del.icio.us

Once again I have gone through the process of customizing the way the ValidationControls are rendered in particular I need them to render an image. I have described a workaround of how to get them to render as images. The problem is that you have to tweak each validator that you want to use. In the same workaround, I have described, why it is not possible to use use Control Adapters to achieve the goal - the really important part that makes validation controls work is hidden in the Render method which is not called by the WebControlAdapter. Today I have learned that Render is called by the ControlAdapter class which is a base class for a WebControlAdapter. If we forget recommendation to use a WebControlAdapter for controls that inherit from WebControl we are almost there.

Almost... It makes a big difference. It turns out, that you cannot customize the element name if you use the ControlAdapter so you cannot change the default <span> element to an <img> element, but at least you can still get the Render method of BaseValidator to be called.

What is my opinion on the whole Control Adapters feature of ASP.NET 2.0? The idea was great. This is only a step in a direction where we should have begin and not end. I mean: why the a control needs to know how to render itself? Differently on different browsers. Differently, depending on the configuration, etc. Adapters make it all right. No longer controls have more then one responsibility. But that is only a try. Nice, but still only a try. The example of Validation Controls shows that once something is done wrong, it is very hard to make it right again. The same holds true for most of the existing controls. Just take a look at he amount of code in the CSS Control Adapters.

I only hope that in v.next some of the issues will be fixed. I know unfortunately, that it can only be a hope. There is a lots of code that would have to be rewritten and I don't suppose Microsoft will do it anytime soon :-(

Add to del.icio.us

Introduction of Nullable<T> was a great thing that many of us have been waiting for for a long time. One of the benefits is the implementation of lazy loaded properties.

There are however few gotchas that you have to be aware of. Something that surprised me the most was the implementation of the ToString method:

public override string ToString()
{
    if (!this.HasValue)
    {
        return ""
    }
    return this.value.ToString();
} 

What is unusual with it? Given the following code:

int? i = null;
string s = i.ToString(); 

What would you expect to happen? I would expect a NullReferenceException to be thrown. After some thinking though, I'm not so sure anymore. If we take into consideration a fact that ValueTypes are not ReferenceTypes i.e. there is no reference to a ValueType unless it is boxed, than having no NullReferenceException is perfectly legal and obvious in the described scenario.
The ToString implementation above clearly fulfils this assert so there will be no NullReferenceException even if Nullable value is null.
Is it good or bad? Now when I know about it, it doesn't really matter that much for me, but I was very surprised nonetheless. I think though that since null is not really null in case of ValueTypes, maybe there should only be a HasValue property? That would however made using Nullable types a lot more cumbersome... Nothing is ever easy .

Add to del.icio.us

Today while working with ASP.NET I have received a "Internet Explorer cannot display the webpage" error when I tried to get to one of the pages. Other pages worked well. My first thought was to use a debugger of course and so I did only to be presented with a following message:

---------------------------
Microsoft Visual Studio
---------------------------
Unable to start debugging on the web server. Could not start ASP.NET or ATL Server debugging.

Verify that ASP.NET or ATL Server is correctly installed on the server.
---------------------------
OK Help
---------------------------

Strange...
I haven't changed anything in my computer's software configuration for a while now. Why would debugging stop to work when it worked well just few minutes ago?
It had to be somehow connected with that one page I thought so to get this solved I needed a working debugger. First I have killed the w3wp.exe process - didn't help. Next I have restarted a website in IIS - didn't help. Finally I went and restarted the World Wide Web Publishing Service and it did the trick. I had a working debugger so I could work on the main problem.
As it came out, I have made a simple mistake and caused an infinite recursion which caused a StacOverflowException to be thrown. After I have found the problem and corrected it my problem with a debugger came back! Aha! So if there is a StackOverflowException, something gets broken in the IIS!
Few tests confirmed it. I have observed that if a StackOverflowException is thrown while navigating to a page (without debugger attached) - nothing happens. You can do it "safely". If however, you are debugging and StacOverflowException is thrown inside your debugger, it usually takes only one such exception to kill IIS.
How important is this problem? It depends of course, but imagine what would happen if you have debugged a server running a couple of sites and all went down for no apparent reason while you have debugged your code. Fortunately usually it is not possible to run a remote debugger on a shared hosting environment

Add to del.icio.us

Today I have noticed the existance of an attribute inside System.Web.UI namespace, that made me curious. The attribute was: NonVisualControlAttribute. It was the first time I have seen it (or I don't remember it).

What does this attribute do? The name suggests that it maybe used by some visual tools. The MSDN documentation is not very useful (as usual) providing only information I have already figured out just by looking at the class name: "Defines the attribute that indicates whether a control is treated as a visual or non-visual control during design time" (MSDN). 

So what does this attribute do? I have searched the Internet for a while and found nothing useful, other than what I already knew. Then I have found that Visual Studio 2005 allows you to toggle whether to display Non Visual Controls using View menu. (you have to be in design mode to see this option). When you select not to display Non Visual Controls, they disappear from the design view like it would be expected. Is it useful? I don't know I have never needed such a feature and fortunately, by default, everything is visible.

Being curious, I have checked which controls have the NonVisualControl attribute applied and I have found that there are only 5 in the BCL:

• DataSourceControl
• HierarchicalDataSourceControl
• ProxyWebPartManager
• WebPartManager
• HiddenField

When you look at the controls above, the important thing to notice is that "Non Visual" does not mean that the control does not render any html markup. As you can see, the HiddenField is also a NonVisualControl but it renders an input tag. WebPartManager on the other hand renders some JavaScript code.

Finally I have found a post on the very attribute written by Nikhil Kothari where he says the following: "Hopefully, it will be used to do more in the future, so start using it now, where it makes sense."

Add to del.icio.us

While working with Visual Studio 2005 the other day I have noticed that my Keyboard Repeat delay has increased. It had happened to me a couple of times before. Always when I was working with Visual Studio so that is why I put the blame on it. Usually I haven't done anything to fix the problem, because it was not very annoying, and usually I could work with it until the end of day. After a restart, everything goes back to normal.

Today I had this problem again, but there were still few hours until the next restart. I had one idea that I wanted to try to see if it can fix the problem. The idea was to increase the Keyboard Repeat delay using Control Panel-Keyboard options. So I did. First I have increased the delay, applied the new settings and right after that I have decreased it to its normal level - the minimum. Voila, every thing worked like a charm. Even Visual Studio!

I wonder if any of you also has this strange problem?

Add to del.icio.us