We Keep Coding

Event wont work with user control

I have a problem that I can't resolve on the server side of my project.
I'll explain:
I have a page named Global,this is ASP.NET page.
This page uses a UserControl named CateGories.
Now I have a button on this UC page,that when I press I want to invoke a function on the Global page that makes a connection with my DB.
I decided to use delegates(events)
This is the code.
Global page:
//here i add my function to the event
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
ShowCurrentTime.Text = DateTime.Now.ToString();
}
CateGories ClassCat = new CateGories();
ClassCat.MainDel += PopulateLinks;
}
//this is the function that the event will run
public void PopulateLinks(string CategoryName)
{....}
Code of the UC page (CateGories):
//delegation of the event
public delegate void Click(string ButtonName);
public event Click MainDel = null;
//function that invokes when I click a button
protected void News_Click(object sender, EventArgs e)
{
if (MainDel != null)
{
MainDel(News.Text);
}
}
Now everythig should work fine, but there is a problem, when the compiler gets to the
if(MainDel!=null)
...
It doesn't get in the function, there go MainDel is null.
I can't see the problem here, why after I insert function to MainDel, its gets null eventualy...
I'll be happy if someone can help
thanks.
Max.

I think I've encountered this problem before, when working with web applications the way I would a windows application.
The problem lies in that when the page gets reloaded, a new instance of your page class is created so any values from the last server interaction are lost.

MainDel is indeed null for what I can see.
You're creating one instance of CateGories on your Web Form and another one on your User Control. And once you check it for beeing null on the UC the reference is to the not initialized object.
One possible way to do that is creating and adding the User Control programatically to the page before PageLoad() and keeping a reference to it so you can access it's properties.
Another solution could be using Page.FindControl to find the UC and make the subscription to the event.
The method names above may be incorrect, it's been a long time without working with web forms.

Why does adding children to composite server control enlarges view state?

I have composite web server control, which at the moment doesn't perform any actions. My aim is to place inside it child controls beginning with checkbox. I try to do it in the following way:
[DefaultProperty("Text")]
[ToolboxData("<{0}:SubmitImageControl runat=\"server\"></{0}:SubmitImageControl>")]
public class SubmitImageControl : CompositeControl
{
private CheckBox _checkBox;
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
}
protected override void CreateChildControls()
{
_checkBox = new CheckBox();
Controls.Add(_checkBox);
base.CreateChildControls();
}
protected override void RenderContents(HtmlTextWriter output)
{
_checkBox.RenderControl(output);
}
}
Registering and placing on the page:
<%# Register TagPrefix="uc" Namespace="PostBackHandlerApp.Controls" Assembly="PostBackHandlerApp" %>
<uc:SubmitImageControl runat="server" />
Checkbox appears on the page and everything seems fine until we look at the view state. Its value is
/wEPDwULLTExMTg2MzM0NjJkGAEFHl9fQ29udHJvbHNSZXF1aXJlUG9zdEJhY2tLZXlfXxYBBR1jdGwwMCRNYWluQ29udGVudCRjdGwwMCRjdGwwMD+PWeqrbtVyQSNMxvfjcmJkKAwpIuEPWJd+m5W6eJtQ
Then, if we simply remove the code Controls.Add(_checkBox);, view state size reduces greatly:
/wEPDwULLTExMTg2MzM0NjJkZLrri0oSGPS9ZiOTsRtSageoskXzCME4KCdRZxOiJyR9
If I move the code of child initialization and adding to OnInit method of my control (where, as far as I know, view state tracing is still disabled), result stays the same. Also, this MSDN article recommends to perform initialization only in CreateChildControls method:
You should create the child controls in the CreateChildControls method and not in OnInit or another life cycle phase. The server control architecture relies on calls to CreateChildControls whenever the Controls collection is needed, such as during data binding (if applicable).
Could anyone explain me why view state becomes larger? Thanks in advance.

Have you tried disabling viewstate for the checkbox in the control. I preusme the viewstate has to account for this control unless you specify otherwise? If you want to easily use this control within the lifecycle though you would want to leave the viewstate enabled.

The reason why viewstate is populated is implementing IPostBackDataHandler interface by large part of data controls, including checkbox. Interface's method LoadPostData is called automatically after the LoadViewState event and viewstate gets populated from the posted data.
Here is nice article about it.

Load Dynamic Control in Asp.net (Asp Page Lifecyle)

I have a function to load a user control, it looks like this:
private void AddPopupControlToPage()
{
WidgetConfiguration popupControl = new WidgetConfiguration();
popupControl = (WidgetConfiguration)LoadControl("~/Docking/Widgets/WidgetConfiguration.ascx");
popupControl.ID = "PopupControlInput1";
g_PopupControlId = popupControl.ClientID;
popupControl.Attributes.Add("width", "150px");
Form.Controls.Add(popupControl);
}
I have drop down that allows me to change the page layout based on what template is selected. I should be able to press call the popup control from any template(page). Based on what I've read here http://msdn.microsoft.com/en-us/library/ms178472.aspx I should be able to load my control in the Page_PreInit event, however the form is not loaded at that point and I get a null reference error. Any ideas on how/where I should load my popup control and keep it available to any selected page?

you should load a control always overriding the CreateChildControls method
soomething like
protected override void CreateChildControls()
{
base.CreateChildControls();
//now load your control here
}

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.

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.