The second issue is that user controls are in their own scope and don’t have immediate access to the rest of the page. That is both a blessing and a curse; good control design means that the controls should be fairly independent of each other but a more pragmatic developer will also note that user controls exist primarily so that numerous copies of the same thing can be easily created and that making entirely self contained controls leads to a lot of unnecessary duplication.

Fortunately there are workarounds for both of these issues.

Regardless of view state, a user control can pass information and therefore trigger events properly using the ASP framework by means of some elaborate JavaScript trickery. In this example, I am using JQuery and JavaScript to allow a click event inside a ViewStateless user control to set the value of a text box and click a button outside of the control, thereby triggering an event within the ASP framework.

$(JQueryObjectForMyUserControl).find(".clickableElement")
.unbind("click").click(function() {
        var clickHandler = $(this).parents(".OuterBound").find(".ClickHandler");
        //I'm replacing the underscores with dollar signs here because that is what ASP expects to find internally
        var argument = $(this).find("a").attr("id").replace(/_/g, "$");
        clickHandler.find(".ClickHandlerArgument").val(argument);
        clickHandler.find(".ClickHandlerLinkButton").click();
    });

Getting around the scope restriction requires a great deal less insanity. For example, my user controls have to be able to activate a modal overlay and dialog box. I could put the code for that inside each user control but that would be a lot of code bloat. Instead, I have the dialog in one place on my page and allow the controls to set its values and activate it.

Page page = this.Page;
ModalPopupExtender ModalPopupExtenderLockedDialog = (ModalPopupExtender)page.FindControl("ModalPopupExtenderLockedDialog");
Label LabelMessage = (Label)page.FindControl("LabelMessage");
ModalPopupExtenderLockedDialog.Show();
LabelMessage.Text = "Hello World!";

Getting to properties is only a little harder. If you need to get to the properties of your page you need only cast this.Page appropriately.

People familiar with C# know that C# supports the inclusion of user defined controls called WebControls.  These are more or less very simple C# programs which can be man-handled by another bit of C# code.  They’re handy for making your code modular: you might design a web-control that takes and validates a credit card number, for example.

But WebControls are notoriously tricky beasts and over the course of the last few weeks I’ve come to understand that one of the reasons for this is that they don’t behave quite the way you might expect them to when they are serialized and deserialized.

Most C# serialization occurs behind the scenes in something called the ViewState.  For those of you who have no idea what that means, ViewState is C#’s rather clever way of persisting the things on a webpage so that it feels a little more like a desktop application.  The long and the short of its behavior is that things get serialized into the ViewState just before rendering and de-serialized back out of ViewState on the next request as part of the load step.

Most controls go into the ViewState… but WebControls don’t.  At least, they don’t go in there by default.  Presumably you can create custom ViewState serialization for them; I have not tried this.  Instead, I serialized my WebControls very simply into Session and coded that storage into a property.  My code looked something like this

private Widget InternalWidget
{
	get
	{
		Widget result;
		if (Session["Widget" + this.UniqueID] != null)
		{
			result = Session["Widget" + this.UniqueID] as Widget;
			if (result == null )
			{
				result = WidgetFactory.Create();
				result.Arguments = InternalActivePortlet.Arguments;
			}
		}
		return result;
	}
	set
	{
		Session["Widget" + this.UniqueID] = value;
	}
}

Now, as expected, none of my EventHandlers persisted when the WebControl came back out of its session serialization.  The object that comes back from serialization is an entirely new object; the old one has been destroyed.  As a result, the event handlers in the deserialized object point to null function pointers.  C# doesn’t throw an error when you call a null function pointer, however; it just goes on its merry way and does nothing.

But the function pointers – even though they now point to null objects – remain.  C# remembers a great deal more about the session-serialized object than one might think including – and this is the part that really threw me – the fact that it’s already been through the ASP parser.

I had expected, since my event handlers weren’t working when the WebControl came back from Session, that the events themselves were gone and that therefore the object returned from session was new — as if it was programatically created for the first time.  This is not the case.  When you programatically create a WebControl for the first time it’s ASP file is parsed and event handlers are set up based upon the code there.  When you deserialize a WebControl from session, however, C# remembers that it has already dealt with its ASP code and does not do it a second time.

Consequently, none of the event handlers defined in the ASP work either.

I expect that all of this seems rudimentary to more experienced C# developers, but to me it was quite a mystery and it took me some time to work out the above logic.  Hopefully this will aid some neophyte coder working through the same issues I had.

On a totally unrelated note: I need to find a decent code display plugin for WordPress…