0

OK Time for another dumb Q from yours truly.

I have a control that has some properties that need to be persisted in the ViewState. I also need to make sure that the properties aren't overwritten if the control appears more than once on the page.

I thought to write something like...

ViewState[String.Format("{0}_{1}", "BaseKey", this.ClientID)] = ...

But the value of ClientID changes partway through the page's lifecycle. It starts out as something like "MyControl1" and then becomes "ctl001_MyControl1". So any values applied before it changes are lost.

The same thing happens if I use UniqueID instead.

I know I'm missing something obvious, and I'm going to blame the pills I'm taking so I don't look too dumb.

-- Stuart

ColinE
  • 68,894
  • 15
  • 164
  • 232
Stuart Hemming
  • 1,553
  • 2
  • 21
  • 44

3 Answers3

2

it looks like you are doing this inside the user control, if that is true you do not need to make a unique key for the viewstate, each instance of every control manages it's own viewstate so all you need is a key known to your control, something like that:

ViewState[@"somekey"] = ...
Kris Ivanov
  • 10,476
  • 1
  • 24
  • 35
1

Try doing it on Page_PreRender rather than Page_Load?

Jon
  • 38,814
  • 81
  • 233
  • 382
1

Don't store the value named relative to the output name of the control itself. Provide it with a unique, unchanging name and then make sure all of your binding rules adjust to that name instead of the client name.

Edit:
As a small example of what I mean:

MyControl ctrl1 = new MyControl();
ctrl1.ID = "MyControlA";
ctrl1.Text = "Some text";
ViewState[ctrl1.ID] = ctrl1.Text;

MyControl ctrl2 = new MyControl();
ctrl2.ID = "MyControlB";
ctrl2.Text = "Some other text";
ViewState[ctrl2.ID] = ctrl2.Text;
Joel Etherton
  • 37,325
  • 10
  • 89
  • 104
  • But then I need to persist the unique value I've used and I need to make the persistence key I use to save that value unique and... – Stuart Hemming Jan 27 '11 at 12:46
  • @Stuart Hemming - I'm not sure I follow. If you call this variable `Steve` then it's always `Steve`. It's put in the ViewState and it never changes. At some point in your code behind there's a unique identifier for it that has nothing to do with the client's id. Even if you're dynamically generating an id for it in the code behind it has an id. If you're really hell-bent-for-leather on using that id, you can always break the clientID string up by splitting it on `_` and using the final index as your ID. – Joel Etherton Jan 27 '11 at 12:52
  • I'm obviously being really dim here. If I have 2 instances of MyControl - MyControlA and MyControlB and I have a property called "Steve" that I save to the viewstate, isn't any attempt to write to MyControlA.Steve (persisted as "Steve" in viewstate) going to to mess with the value previously saved for MyControlB.Steve (also persisted as "Steve" in viewstate, using the same code)? If I create a unique key for MyControlA and MyControlB I need to persist *that* value someplace so I can get at it later. Don't I? – Stuart Hemming Jan 27 '11 at 13:01
  • @Stuart Hemming - precisely. You'd have MyControlA and MyControlB, but that would be determined by the ID in the code behind (hopefully) rather than the ClientID (which is changeable). So in the code behind when you instantiate your control, you would set its ID directly with some control specific value (like MyControlA) and that becomes the key in the viewstate. Dynamic controls added in for loops present different problems related to that uniqueness, but it doesn't sound like you're doing that exactly. – Joel Etherton Jan 27 '11 at 13:20
  • @Stuart Hemming - added a dirty code snippet to describe what I mean. – Joel Etherton Jan 27 '11 at 13:23
  • Gotcha! Ta. I am too dim to be allowed out on my own, sometimes. – Stuart Hemming Jan 27 '11 at 14:59