«

I was wondering if there was already a common practice / pattern before I
run off and try building a better wheel. How do developers handle Loading
the Viewstate when the user has set a value prior to the ViewStateBeing
loaded.
For example upon a prior Postback a control is disabled or set to another
state.
This state was stored in the viewstate.
Now this time the user has chosen to do some logic in the OnInit of the Page
and he sees that his conditions are matched so he sets the Control who was
prior disabled to enabled. Do most developers maintian a table so that this
property is not overwritten when the ViewState is loaded or do most
developers just let it overwrite ?

not sure of any best practices, but my suggestion is to write to the
viewstate using your code, so this will be consistent with the viewstate
processing model.

"" wrote:

> I was wondering if there was already a common practice / pattern before I
> run off and try building a better wheel. How do developers handle Loading
> the Viewstate when the user has set a value prior to the ViewStateBeing
> loaded.
> For example upon a prior Postback a control is disabled or set to another
> state.
> This state was stored in the viewstate.
> Now this time the user has chosen to do some logic in the OnInit of the Page
> and he sees that his conditions are matched so he sets the Control who was
> prior disabled to enabled. Do most developers maintian a table so that this
> property is not overwritten when the ViewState is loaded or do most
> developers just let it overwrite ?
>
>
>
>

I appreciate the completely unrelated comment. I will go ahead and
restate my question again.

Is there an existing design / preference to handling how properties
that are stored in a viewstate are handled when a developer chooses to
set the value of one of these properties before the view state is
loaded.

Do most control developers consider that person to be sol and overwrite
changes he made prior to viewstate being loaded.
Do most control developers allow this change to be made and if so is
there a tried and proven method to keeping track of tehse changes so
that a viewstate restoral does not overwrite properties that have been
set prior to the viewstate being loaded while restoring values that
have not been set

Hi Marc,

From your description, you're wondering some best means to manage the
WebControl's custom properteis which will be persisted in ViewState.
Also, sometimes when we adjust those properties before the Page's
LoadViewState, they should be prevented from being override by the old data
retrieved in LoadViewState, yes?

I'm not sure whether there is any well-known pattern on this. As my own
opinion, I'll define my Control properties as the following style. The
public property is a wrapper of a private member variable which hold the
actual values and it is not directly accessing the ViewState, we read it
from and write into ViewState in our override LoadViewState and
SaveViewState. In addition, we can also define a certain value as the
default(empty) value of that property, thus, in the LoadViewstate, we can
determine whether to override the value or not in LoadViewState according
to whether the private variable's value is the empty value. How do you
think of this?


======================
......
private string title = null;
..............

public string Title
{
get
{
return title;
}

set
{
title = value;
}
}

protected override void LoadViewState(object savedState)
{
Triplet triplet = (Triplet)savedState;

if(title == null)
{
title = triplet.Second as string;
}

base.LoadViewState (triplet.First);
}

protected override object SaveViewState()
{
object baseState = base.SaveViewState ();

Triplet triplet = new Triplet();

triplet.First = baseState;
triplet.Second = title;

return triplet;

}
================================

If you have any other ideas, please feel free to post here.

Thanks & Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

That works good for strings, however for any value-type (Numerical
values, enumerations, boolean, etc) that cannot be null this idea does
not operate as well.

Hmmm it seems responses are not getting posted properly.

Thanks for your followup Marc,

Yes, I admit that that means may not works very well for value types or
some other primitive types. But we can still workaround it by defining some
wellknown const values for empty value. Otherwise, we may need to use
addiontal variables to indicate whether our properteis should be override
by VIEWSTATE or not. How do you think?

Thanks & Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)