We Keep Coding

Load Server Control from Assembly and hook up events

I have several Server Controls, each in a separate assembly and I'd like to load one of them dynamically into a page depending on some choice. There seems to be a problem where the server side events in the control are not firing however.
e.g. Controls are of the form:
[ToolboxData("<{0}:MyPlugin runat=server></{0}:MyPlugin>")]
public class MyPlugin : WebControl, PluginSystem.Interface.IMyPlugins
{
protected override void RenderContents(HtmlTextWriter output)
{
...
_btn = new Button();
_btn.ID = "btnSave";
this.Controls.Add(_btn);
_btn.Click += new EventHandler(btn_Click);
_btn.RenderControl(output);
}
void btn_Click(object sender, EventArgs e)
{
//do something. This doesn't fire
}
}
The controls are loaded from their assemblies:
public static IMyPlugins GetPlugin(string assembly, string type)
{
var t = Type.GetType(type + ", " + assembly);
IMyPlugins rtn = (IMyPlugins)Activator.CreateInstance(t);
rtn.Initialise();
return rtn;
}
How do I inject the loaded assembly into a page so that the events in the control will fire? Is that possible?
Thanks for any help!

You're adding the controls way too late in the page lifecycle. Add the server side controls in the OnInit Page event is your best bet.
Check out this link for an overview of the lifecycle process. The controls need to be created by the time the postback event handling happens. This series is also really good.
Dynamically changing the page based on user choice can be a pain in the ass because of this. There are a few options to go with. The easiest way is to add all your controls in the OnInit and then remove them when you know the selection the user made.
If it's truly completely dynamic, and you have no idea what control you are going to render until after the postbacks have been handled, it can be easier to step away from ASP.NET's viewstate/postback system and check things yourself. You can always get the full range of post values at any time in the page lifecycle by checking the Form.Request collection.

Asp.NET custom server control event handler not firing on second postback

I'm developing a custom server control in Asp.NET (.NET 3.5) which inherits the CompositeControl class. Inside my control I'm overriding the CreateChildControls() method to generate a mixture of html and Asp.NET server controls. Some of the Asp.NET controls which are added are LinkButtons (which each have their Command event handler set to a method within my control). What I'm finding is that the first time one of these LinkButtons is clicked a postback is triggered and the event handler method is correctly fired. Inside this event handler method CreateChildControls() is explicitly called to regenerate the control in response to the postback. What I then find is that subsequent clicks of the LinkButtons postbacks fail to raise the event handler method.
I assume that the way I'm handling the regeneration of the control on postback must be at fault, but I can't figure out what to do - I am aware of the fact that on that first postback CreateChildControls() is called twice which probably isn't ideal but since CreateChildControls is called before any events are raised, I don't see a way around this.
A simplified version of my control class is shown below:
public class SearchResults : CompositeControl
{
private int PageIndex = 0;
protected override void CreateChildControls()
{
//do stuff here e.g.
LinkButton prevLink = new LinkButton();
prevLink.Text = "< Prev";
prevLink.CommandArgument = (PageIndex - 1).ToString();
prevLink.Command += new CommandEventHandler(PagerLinkCommand);
this.Controls.Add(prevLink);
}
protected void PagerLinkCommand(object sender, CommandEventArgs e)
{
PageIndex = int.Parse(e.CommandArgument.ToString());
CreateChildControls();
}
}
EDIT
The problem here was caused by the fact that the control is used in a Sitecore site and I had forgotten to register the control type in the web.config file with a <typesThatShouldNotBeExpanded> entry. This entry is used to prevent server controls from having their events messed up by Sitecore - this can cause similar problems for standard server controls such as ListView, GridView and Repeater etc. My web.config was modified as shown below:
<typesThatShouldNotBeExpanded>
<type>System.Web.UI.WebControls.Repeater</type>
<type>System.Web.UI.WebControls.DataList</type>
<type>System.Web.UI.WebControls.GridView</type>
<type>MyNamespace.MyCustomControl</type> <!-- This is the bit I added -->
</typesThatShouldNotBeExpanded>

In my experience this sort of problem is usually due to not assigning an ID to dynamically generated controls.
LinkButton prevLink = new LinkButton();
prevLink.ID = "prevLink";

Apologies... this is not a complete answer, but a debugging suggestion that is too long for a comment:
In your browser save an HTML copy of your page for initial load, postback load, and second postback. Then compare the files using your favorite comparison tool. Eliminate obvious differences like search results, etc. This can help you pinpoint any issues with control IDs, missing controls, etc.
The two absolute keys to successful dynamically created controls are
1) Creating them at the correct time during the page lifecycle
2) Re-creating the EXACT SAME control hierarchy (including IDs) on postback

To get the proper control tree override the Controls property and call the EnsureChildControls, and also call the EnsureChildControls and not the CreateChildControls inside the PagerLinkCommand.
/// <summary>
/// Gets controls.
/// </summary>
public override ControlCollection Controls
{
get
{
EnsureChildControls();
return base.Controls;
}
}
/// <summary>
/// Create child controls.
/// </summary>
protected override void CreateChildControls()
{
this.Controls.Clear();
//do stuff here e.g.
LinkButton prevLink = new LinkButton();
prevLink.Text = "< Prev";
prevLink.CommandArgument = (PageIndex - 1).ToString();
prevLink.Command += new CommandEventHandler(PagerLinkCommand);
this.Controls.Add(prevLink);
}
protected void PagerLinkCommand(object sender, CommandEventArgs e)
{
PageIndex = int.Parse(e.CommandArgument.ToString());
EnsureChildControls();
}

The reason for this behaviour was not down to the server control itself, but was Sitecore-related. In order for Sitecore to not interfere with server control postbacks, it is necessary to add an entry under the typesThatShouldNotBeExpanded section in the web.config file as shown below.
<typesThatShouldNotBeExpanded>
<type>System.Web.UI.WebControls.Repeater</type>
<type>System.Web.UI.WebControls.DataList</type>
<type>System.Web.UI.WebControls.GridView</type>
<type>MyNamespace.MyCustomControl</type> <!-- This is the bit I added -->
</typesThatShouldNotBeExpanded>

Minimizing ViewState size in ASP.Net, is there a difference between initializing control values in the constructor versus OnInit?

Ok I'm trying to understand how best to handle ViewState, for the programmatic setting of default values using C#. I understand that the construction of the ViewState hidden field is based on every value that is set after the OnInit event is triggered. What I'm not clear about is if there is a difference between using the control's constructor or the OnInit event to set default values.
public MyControl(){
this.Text = "SomeDefaultValue";
}
versus
protected override void OnInit(EventArgs e){
this.Text = "SomeDefaultValue";
}
I've seen some places that suggest testing the ViewState value for null in the get of the given property, like so:
public string Text {
get {
return this.ViewState["Text"] == null ?
"SomeDefaultValue" :
this.ViewState["Text"] as string;
}
set { this.ViewState["Text"] = value; }
}
I don't like that because it makes clearing the value confusing.
So, Is there any functional difference between using the constructor vs OnInit to set default ViewState values?

In terms of minimizing ViewState, there is no difference, as ViewState starts tracking after the OnInit method is run.
There are some functional differences, however: until the control is initialized, you cannot access other properties like the Page. For this reason, I usually prefer to use either OnInit or some handler tied to the Init event.
Also, be careful about overriding OnInit: you should call base.OnInit() to make sure that other event handlers for the Init event still get called.
I highly recommend that you read this excellent article on the topic: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
Edit
To clarify, the ViewState starts tracking for a given control after the OnInit method is run for that control. So in the given example, you are safe to override OnInit like this:
protected override void OnInit(EventArgs e){
this.Text = "SomeDefaultValue"; // Make sure this happens before base.OnInit
base.OnInit();
}
This works because the Text property is saving the value to the ViewState of this control. However, let's say you have another child control (I'll use a Label as an example). That Label's OnInit will already have been run by the time your control's OnInit method is called. So if you want to change the Label's Text value, you'll need to do it during that label's OnInit phase (or sooner).
You could do it in the constructor of the current control:
public MyControl(){
this.Label.Text = "SomeDefaultValue";
}
... but as mentioned earlier you won't have access to the external control structure, which may be necessary in some cases. A good alternative in these cases is to use an Init event handler on the label itself. You can hook up the event handler itself in your constructor:
public MyControl(){
this.Label.Init +=
(sender, e) => this.Label.Text =
((TextBox)Page.FindControl("SomeControl")).Text;
}
... but this will only work if the control is declared directly as a member of your class. If the label is inside a template (like in a Repeater), you'll need to use markup to hook it up:
<asp:Label runat="server" OnInit="Label_Init" />
with the code-behind:
public void Label_Init(object sender, EventArgs e)
{
var label = (Label)sender;
label.Text = ((TextBox)Page.FindControl("SomeControl")).Text;
}
This latter example has the advantage of working in just about every circumstance I can think of, but it requires more boilerplate code, as well as a change in markup. So pick your poison based on your specific situation.

There is quite a detailed document on the ViewState over at MSDN:
...server controls don't begin tracking
view state changes until right at the
end of the initialization stage.
Second, when adding dynamic controls
that need to utilize view state, these
controls will need to be added during
the Page's Init event as opposed to
the Load event.
Just from this alone, I would say, if you're utilising the ViewState, use OnInit.

Databinding best practice for User Controls in Web Forms

I was wondering about some best practices for data binding in web forms.
For example we have a control:
public partial class MyUserControl : UserControl
{
public override void DataBind()
{
//#1
base.DataBind();
//#2
}
}
If we wanted that control to bind its data automatically we would do something like this:
protected void Page_Load(object sender, EventArgs e)
{
if (!this.IsPostBack)
{
this.DataBind();
}
}
In the first section of code if we do our data binding before the call to base.DataBind() (#1) then that means that, if for example we databind a ListView, we don't have to call ListView.DataBind() because when we call base.DataBind() on our control it recursively calls DataBind on all child controls. Also, we won't have access to any of the properties of the control that were assigned to it using the data binding code blocks <%# %>
If we do our binding on our controls after base.DataBind() (#2) then this means that DataBind is called on these controls twice. Once when base.DataBind() is called, and the second time when we are forced to call control.DataBind().
Does anyone know of some sort of pattern I can follow here that I don't know about?
Am I making any sense here?
What am I doing wrong?
EDIT:
Looking at this page:
http://msdn.microsoft.com/en-us/library/w5e5992d.aspx
Use this method to bind data from a
source to a server control. This
method is commonly used after
retrieving a data set through a
database query. The method is
primarily used by control developers;
most controls perform data binding
automatically.
It appears that best practice is to bind controls data automatically. Databinding is for when we explicitly set a data source.

I've encountered problems previously, when pages become complex and you are relying on user controls binding their own data in the page load event. This has resulted in some long debugging sessions, as you can't be guaranteed exactly when this page load event in the control will fire.
Now, that said, these pages weren't too well designed, and we shouldn't have run into this problem, but I prefer to stick with the explicit and have my page tell the child controls when to do their thing - you may wish to avoid calling base.DataBind and do it explicitly instead - you may also wish to not override the DataBind method in this way and instead call the method on your control by another name.

Why can’t Themes and Master pages be applied dynamically after Page.PreInit event?

1) I assume Themes can be set programatically only inside Page.PreInit event handler due to the following reasons:
if we’d set a Theme inside Page.Init event handler, then by that time ViewState would already be tracked and thus any data applied by Theme would be tracked and marked as dirty ( which would consume lot of bandwidth ) ?
and if we’d set it after Init event, then Themes could also override deserialized ViewState data applied to individual controls?
Are there any other reasons why Themes can’t be set after Page.PreInit?
2) Also, why can't Master pages be applied after Page.PreInit?
thanx

According to this:
http://odetocode.com/articles/450.aspx
The 'MasterPageFile' property can only
be set in or before the 'Page_PreInit'
event.
This exception makes sense, because we
know the master page has to rearrange
the page’s control hierarchy before
the Init event fires
The article also includes this example:
using System;
using System.Web.UI;
public class BasePage : Page
{
public BasePage()
{
this.PreInit += new EventHandler(BasePage_PreInit);
}
void BasePage_PreInit(object sender, EventArgs e)
{
MasterPageFile = "~/Master1.master";
}
}
Or, an approach I've used before:
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
if (Request.QueryString["Master"] == "Simple")
MasterPageFile = "~/Masterpages/Simple.Master";
}

Are there any other reasons why Themes
can’t be set after Page.PreInit?
Yes. Themes includes skins, which can specify properties for controls. Those properties need to be set during the Init event, so the desired theme needs to be selected before then.
ViewState tracking may be an issue, but I think it's a minor one compared to the above.
Note that a StyleSheetTheme (preferable to a regular Theme, IMO), is actually set from an overridden property on the Page, not by setting the value of the property itself (unless you set it from an HttpModule).
why can't Master pages be applied
after Page.PreInit?
Controls determine their IDs and various other characteristics and properties based on their location in the control tree (including things like accessing the form control, etc). A Master Page acts as what amounts to a set of parent controls, so controls can fully initialize themselves until that parent structure is in place. Initialization happens during the Init event, so the Master Page needs to be selected before then.