Storing Controls as session variables?

[Alex D.]

is it possible? pros and cons?

 

[Umut Tezduyar]

Don't forget that, if your clients browser disables cookies in his computer,
session will not be used by him.

 

[Robbe Morris [C# MVP]]

Why would you ever want to do this? I could see
storing the data used to populate the control
by why the entire control itself? Tons more
overhead with no additional benefit...

 

[Alex D.]

so..your answer is? yes or no?

Why would you ever want to do this? I could see
storing the data used to populate the control
by why the entire control itself? Tons more
overhead with no additional benefit...

 

[Peter Rilling]

The answer is both yes, and no. Yes you can store any object you want in
sessions, including control instances. But, upon return trips, the instance
you have in session will no longer map to the instance built when ASP.NET
constructs the object model, therefore, any changes made to the object in
session will not be reflected in the page output. The object model is
rebulit on each request.

 

[Alex D.]

but instead...the other way around any changes in the original control will
be reflected in the session object?? uhmmm

 

[Peter Rilling]

Obviously not if they do not reference the same object.

It might be something like the following example:

string strA = "hello world!";
string strB = strA;

//
// The two variables refer to the same object just as if you put a control
in the session.
//

strB = null;
strB = "hello world!";

//
// Just as with a page request, strB above is reset and although contains
the same content, they
// are two different objets in memory.
//

I would imaging the same thing happens with the object model. Changes made
in either are not seen by the other.

 

[Robbe Morris [C# MVP]]

No. Why would you want to store the entire control
in session? I can think of several negatives. What
would be the positive?

That said...

You'd have to research whether the controls
you are saving to session are serializable. If not,
you could never deploy your site in a web farm or
use anything but InProc on a single server.

--
Robbe Morris - 2004/2005 Microsoft MVP C#
http://www.masterado.net

 

[Alejandro Penate-Diaz]

may be your example using strings is not the most appropriate in this case
because strings I think are considered a basic type so it is a value type
and not a reference.
and what it seems to me is that reference types are stored as references in
session variables, but instead of that what I needed was to save it as a
value type so I would be a different object.

 

[Alejandro Penate-Diaz]

a simple use for a TreeView in a session variable is to keep the
collapsed/expanded info for every node when in the postback you redraw the
entire tree and loose all the properties...then you can restore this values
very easily in each postback. so your tree "remember" which nodes where
collapsed and which expanded...
of course there are many ways of doing this...actually I already used a
different approach...but in the session variable didnt work because just
after repopulating the tree also the session stored tree was affected and
all info erased.

 

[henrycortezwu]

Hi, how did you implement the "remembering" of which nodes where
collapsed or expanded?? I'd love to know how you did this.

Thanks!
Henry

 

[Edwin Knoppert]

I didn't know as well.
I currently enum allnodes in a string(builder) "01011" etc.
Which i hold in the session
On page load i set these again.

 

[AJ]

Good answer

I didn't know as well.
I currently enum allnodes in a string(builder) "01011" etc.
Which i hold in the session
On page load i set these again.