views:

186

answers:

3

Hi, I have a listbox control. When the user clicks it, it tells a custom control to use a certain ID to use.

The custom control draws the same thing everytime(dynamically), just loads different content depending on this ID(it's loaded from a database into a dynamic form like control).

Ok, Now I'm having trouble with viewstate spillage. When you click the listbox to load say ID #1, it'll all look good. Then, you click on ID #2 and all the textbox controls created inside the custom control has the same thing that was put in ID #1. So when the listbox index changes I need to clear the view state, but I can't get this to work.

All of the controls are created at Page_Load also.

I tried ViewState.Clear() at Page_Load but that didn't do anything.

I had the custom control derive from INamingInterface, but I guess the IDs still match for viewstate.

I've tried changing the custom controls ID to something unique(like "CONROL_"+id.ToString()) I've also tried doing the same thing with the panel containing the custom control.

I can not seem to get rid of this view state!

EDIT Ok here is code that demonstrates the problem

public partial class _Default : System.Web.UI.Page 
{
protected void Page_Load(object sender, EventArgs e)
{
 if (ddl.SelectedValue == "1")
 {
  Create("ID #1");
 }
 else if (ddl.SelectedValue == "2")
 {
  Create("ID #2");
 }
 }
void Create(string text)
{
 TextBox t = new TextBox();
 t.Text = text;
 pnl.Controls.Add(t);
}
}

the markup:

<div>
    <asp:Panel ID="pnl" runat="server">
        <asp:DropDownList ID="ddl" runat="server" AutoPostBack="True">
        <asp:ListItem Text="id 1" Value="1">
        </asp:ListItem>
        <asp:ListItem Text="id 2" Value="2"></asp:ListItem>
        </asp:DropDownList>
    </asp:Panel>
</div>

If you run this code you'll notice that if you change what is in the textbox and then you change the dropdown list, then what you typed earlier will be kept in there instead of it being overwritten..

My basic goal with this is to get it so that when you change to ID #2, it puts "ID #2" in the textbox no matter what(preferably without disabling viewstate altogether)

+1  A: 

If I set the ID of the Text control then it doesn't retain the old value. Are you giving all controls a unique id?

void Create(string text)
{ 
    TextBox t = new TextBox();
    t.ID = text;
    t.Text = text;
    pnl.Controls.Add(t);
}
Mike J
Not every control because 50-75 are being dynamically created. Is there a way to get it so I can just wrap it in a INamingContainer and just give it a unique ID becuase to do such a huge refactoring just to give pointless IDs to generic fields seems wrong to me
Earlz
The custom controls should implement the INamingContainer interface and then all the controls you dynamically create and want to have update properly should have a unqiue ID within the custom contorl.
Mike J
As painful as it is, this completely fixes the post back issues as well(how controls are restored to postback values after OnLoad)... So now to just go and add IDs to about 40 or 50 controls in code.. .
Earlz
A: 

You can't do it that way.

For viewstate to work properly all controls must be created before it is loaded and with the same id's. So you must store the control definitions in session and recreate then with the same ids to ASP.NET load their properties from the view state. Page_load is too late, do it at PreLoad.

But it is easier to have all controls created at design time with visible set to false, and alternate their visibility so viewstate will work properly.

Wagner
We can't do the whole controls being invisible thing because that would require loading thousands of dynamic controls out of the database at a time(when its really only 30-50 controls at one time on one page). And we can not change it to use PreLoad 1. Because it is in a webpart, so that event is not available, and 2. We can't have it in Page_Init because then viewstate isn't available for the dropdown list.
Earlz
I think it's better for you to create a server control, there you will have all freedom do define what will be saved in viewstate.
Wagner
A: 

Actually this is no longer relevant. We fixed it by just disabling viewstate for our dynamically created controls. This would not work in all instances, but in our case there are two buttons the user can push(that are to do with the dynamic controls) or a list box to switch forms. The two buttons both save the state of the controls to database, so viewstate is not actually needed.(I always get confused when thinking about viewstate and how it interacts with controls.. )

So basic advice: If your having trouble controlling the viewstate, be sure you actually need it.

Earlz
Wait, actually it doesn't work disabling viewstate.. so it's not a viewstate issue... *votes for closing*
Earlz