Weird ViewState issue in a Custom Control

  • Thread starter Thread starter Tracker1 - Michael J. Ryan
  • Start date Start date
T

Tracker1 - Michael J. Ryan

I have a custom WebControl that I am working on, it's weird...

I have two Properties, that I save to ViewState. I know they save, and
have
verified this with the ViewState viewer... When a postback happens, one
of
the properties is there, the other is null... not sure WTF the issue
is...

I tried overriding the LoadViewState and SaveViewState, the save is
called,
but the load never seems to be called... this is ASP.Net 1.1, and 2.0
isn't an
option... any feedback/help would be appreciated.

has anyone had any issues like this before? I've seen a few postings
with
similar issues, but no conclusive answers.... I *could* use a hidden
form
field rendered with the control to track this (I am actually doing that
anyway
for a non-postback mode), but this is unreliable if in a hidden panel
(for
example) the input elements won't be there, I need the ViewState...
 
Tracker1 said:
I have a custom WebControl that I am working on, it's weird...

I have two Properties, that I save to ViewState. I know they save, and
have
verified this with the ViewState viewer... When a postback happens, one
of
the properties is there, the other is null... not sure WTF the issue
is...

How is your control instatiated?

On the aspx or dynamicly?

Thomas Skovsende
 
How is your control instatiated?
On the aspx or dynamicly?

It was actually the parent control that was causing the issue... I was
using Controls.AddAt() inside the parent control's CreateChildControls
overload.. apparently that doesn't work properly... I was able to get
around it, but using Controls.Add() before the
base.CreateChildControls() call... Was a hard thing to find, since the
problem was because of another control.. *sigh* killed almost 2 days on
this issue.

Another thing I hadn't considered, was using the
Page.RegisterClientScriptBlock to put a hidden input field on the
form... in any case, it's working now *finally*.. keyed in on searching
on the LoadViewState overload not firing, which is how I found the
answer.
 
Back
Top