ross dickinson: web and desktop software developer

I discovered this bug/feature today. While working on a new page for work, I was having an issue where none of the child controls inside an ascx user control were instantiating during runtime, leading to all sorts of null reference exceptions. I wasn't quite sure why, as the custom control worked fine on every other page.

After a bit of tooling around, I found out that the problem was in how I registered the control at the top of the page. The problem was here:

<%@ Register Assembly="CompanyName" Namespace="CompanyName.Controls" TagPrefix="companyname" %>

I was trying to register the project's controls namespace so that I didn't have to register each control that I used individually. Visual Studio didn't complain, nor did the compiler. I was able to put in any of the types and it worked out fine. The big mystery is that, for reasons unknown to me, the user controls would instantiate on the page normally, but none of their child controls would. 

Switching the register back to

<%@ Register Src="~/Controls/UserControl.ascx" TagName="UserControl" TagPrefix="companyname" %>

And everything worked fine again.

The only thing I can figure out is that this is specific to user controls that have a designer file. External control libraries still work fine.

Update!

I finally realized why this was happening. Because the "ascx" part of a user control is a template, the template doesn't get loaded unless it's registered specifically. You can get around this by going: CustomControl.LoadTemplate("ascx path")!

Cleaning up ASP.Net WebForms markup

by Ross on November 19, 2010 at 1:08 PM under ASP.Net | Programming

One thing that clutters up ASP.Net websites is the amount of excessive markup created by controls.

One way to reduce the overall page size of the final output is to null/remove ID's on controls created in markup that don't need it. This often pops up because you've created a label, button, or some other control in the markup that you need to access from the code behind. If the control isn't being used on the client-side(through javascript, form validation, or some other purpose), you can safely set the ID property to null to prevent ASP from rendering the attribute. This is espescially helpful in versions previous to .Net 4, where you could potentially get id fields like "ctl00_ContentPresenter1_Parent_Child_GrandChildren_CabDrivers_lblStatus" mucking things up.

Consider this before going ahead: Objects relying on the FindControl method will still require that the ID attribute be set in order to find it. To avoid causing problems, you should null the ID property during the rendering phase. This can be done on the page level or the control level.

I just added a new fork on BlogEngine's codeplex site that adds widgets to the available areas themes have access to. Hopefully it'll get added to the main release!

Originally, BlogEngine was adding extra markup inside WidgetBase's Render method, which made it impossible to change unless you had access to the source code. That's usually not the case when dealing with theme creation. Later on, another change was made to WidgetBase that allowed it to support Photoshop image slices that only needed to be altered with CSS. While this is probably cool for a few people, this mostly just added a lot of excess markup to the final page. I'm a man who likes his markup slim, so this bugged me.

I thought it over a bit and realized that making a similar setup to the PostView/CommentView classes would allow a lot more flexibility and customizability for users. I created a class called WidgetContainer, a simple UserControl derived class thats sole purpose is to house a WidgetBase derived control. This class is easily themed by creating a WidgetContainer.ascx user control and adding it to a theme's directory.

The major benefit of this is that users can now have full control over their widget's markup without needing access to WidgetBase's source code.

To create a WidgetContainer theme, the only thing required is that it contains a control with the ID "phWidgetBody". That control only needs to derive from the Control class and allow children to be added to it. The WidgetContainer looks for this control at load time and adds its Widget instance to it.

Updates on this Site

by Ross on October 1, 2010 at 8:18 PM under ASP.Net | BlogEngine.NET

As someone who loves the .Net framework, I've been running this site using the open source project BlogEngine.NET. However, as I started actually making my own theme for the site, I started to become very aware of the project's shortcomings, bugs, and possible security flaws that currently exist. So please be aware that things may randomly break on this site as I update it from time to time to fix various things that I find broken.

And before anyone asks, I do report all the bugs I find to BlogEngine so that they'll hopefully be fixed in the rumored 2.0 release that's coming out at the end of the year! I'll post more about the bugs if/when they get fixed, cause I'd rather not make them public here.

Having said that, the upcoming release looks good. The admin section has been redesigned a bit to give it a more refined looking appearance, and it makes a lot more use of ajax/web services.

Using Enums in ViewState

by Ross on September 15, 2010 at 9:25 PM under ASP.Net

If you're having an issue with trying to figure out why your ViewStates are so large, check to see if you're storing any enum values inside the ViewState. ASP.Net stores each enum type's fully qualified assembly name inside the ViewState, which really bulks up the ViewState length.

An easy way to get around this is to convert the enum values to their basic value types before storing them to ViewState.

ASP.Net's TextBox class and MaxLength

by Ross on July 26, 2010 at 3:14 PM under Programming | ASP.Net

You learn something new every day!

It appears that ASP.Net's TextBox class doesn't have any built-in validation for trimming the Text property's length if the MaxLength property is set to a value greater than zero.

I suppose this is to give user's more leeway in how they want to validate the control, but it's not immediately obvious that a user can get around this limitation just by altering the html! ie: A user could use the FireFox FireBug extension to remove the textbox input's maxlength attribute and load it up with as much text as they'd like!

So remember kids: Always validate your input!

About the author

rossisdead is a 26 year old web and desktop software developer from New Jersey. He has two cats and likes long walks on the beach.

On Stackoverflow

On Stackoverflow Careers

On Codeplex

On Github