Lessons learned -- ViewState, Server Controls, and Control lifecycle.

Ugh, well... I finally fixed the major issue that has held up my development for 2 days now.It really boileddown to the fact that I had properties that were persisting themselveswith ViewState like this:

Which will work perfectly well as long as you don't access this propertybefore the control's Init event... This is what I have come up with,(and someone please correct me if I am wrong) is that ViewState isreally an IStateBag instance that is given to your control, which isdifferent for each control... This helps eliminate conflicts if I addmultiple controls on the same page... If I try to access the propertybefore this instance is created (which may be when our control is addedto the parent controls collection... I'm not yet sure of this) then Iget a brand new string, not the one that was previously persisted....NET doesn't give you any error or warning that this is happening,which makes it very hard to track down.

The above worked for most of myserver controls, but one in particular was giving me problems. I movedthe persistance code away from the property itself, which I think Ilike better visually anyway, and this seems to have relieved theproblem.This is how you tinker with your controls viewstate:


private string _myName;
public string MyName
{
get { return _myName; }
set { _myName = value; }
}

protected override object SaveViewState()
{
Pair p = new Pair();
p.First = this._myName;
p.Second = base.SaveViewState();

return p;
}

protected override void LoadViewState(object savedState)
{
Pair p = savedState as Pair;
this._myName = p.First as ArrayList;
base.LoadViewState (p.Second);
}
Hopefully this might save someone a few hours of head-scratchin.... it certainly cost me a lot more than a couple headaches.