Re: Viewstate of variables.

Tech-Archive recommends: Fix windows errors by optimizing your registry

The code snippet by far does NOT manage the state of myPerson. The only
thing explicit about it, is I am explicitly storing the item in ViewState.
I could have placed it in Session, Application, Cache, or could have
implemented explicit state management.

ViewState["Person"] points to an instance of myPerson.
Person points to the same instance.

Because ViewState["Person"] points to an instance, no matter how complex
your methods calls are on it, your Person is not actually saved to ViewState
until PreRender. You can make all the changes you want to the internal
workings of your Person object, without reassigning it to ViewState.

How would you expected to have this item persisted?

bill


"Mark Broadbent" <nospam@xxxxxxxxxx> wrote in message
news:eQ%231PQsZFHA.2980@xxxxxxxxxxxxxxxxxxxxxxx
> You are having to explicitly implement coding to manage the state of this
> variable and we are talking more than a couple of lines -especially when
the
> instance variable in question is quite complex such as when it has method
> calls which change its state (that must be saved).
>
> Thanks for suggestion though - it is probably the cleanest way to do this
> (as I unfortunately thought).
>
> Br,
>
> Mark.
>
>
> "William F. Robertson, Jr." <theman@xxxxxxxxxx> wrote in message
> news:e7wfpLrZFHA.2444@xxxxxxxxxxxxxxxxxxxxxxx
> > This is a perfect candidate for a property.
> >
> > I type:
> >
> > protected Person myPerson;
> >
> > Then I run a macro that turns the above code into:
> >
> > protected Person myPerson
> > {
> > get {
> > Person p = ViewState["Person"] as Person;
> > if ( p == null ) {
> > p = new Person( "Mr Happy I don't have to type this every time." );
> > ViewState["Person"] = value;
> > }
> > return p;
> > }
> >
> > set { ViewState["Person"] = value; }
> > }
> >
> > In code I only reference myPerson. You can also continue to set it in
> > Page.Load !PostBack and leave out the new declaration in the property.
> >
> > "Mark Broadbent" <nospam@xxxxxxxxxx> wrote in message
> > news:OZebJDrZFHA.2444@xxxxxxxxxxxxxxxxxxxxxxx
> >> Been a while since I've touched asp.net but one thing that always seems
> >> to
> >> fustrate me is the loss of state on variable declarations. Is there
> >> anyway
> >> (i.e. assigning an attribute etc) to instruct the server to remember a
> >> variables state *without* having to go through the rigmarole of saving
> >> and
> >> loading to and from the Session state manually or similar workaround
for
> > any
> >> Types (including custom types) in exactly the same way web controls
> >> retain
> >> state. I understand the reasons (performance) that this is not done by
> >> default ... but it is really anoying.
> >>
> >> e.g. This would be great...
> >>
> >> [ViewState save=true]
> >> protected Person myperson;
> >>
> >> private void Page_Load(object sender, System.EventArgs e) {
> >> if (!this.IsPostBack)
> >> myperson = new Person("Mr Unhappy");
> >> }
> >> //otherwise myperson still points to an instance
> >> }
> >>
> >>
> >> so that on every postback myperson instance would still exist.
> >>
> >> Any ideas are extremely welcome.
> >> Br,
> >>
> >> Mark.
> >>
> >>
> >
> >
>
>


.

Relevant Pages

  • Re: Viewstate of variables.
    ... via the property from viewstate. ... own state management and that makes things easy (the whole reason MS ... > The code snippet by far does NOT manage the state of myPerson. ... > thing explicit about it, is I am explicitly storing the item in ViewState. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Viewstate of variables.
    ... ViewState is a string keyed collection. ... When accessing the BigCollection property it points to heap address ... > own state management and that makes things easy (the whole reason MS ... >> implemented explicit state management. ...
    (microsoft.public.dotnet.framework.aspnet)