Need to have variables that are persistent with respect to postbacks

I am using ASP.NET 2.0 (VB) and need to have variables that are persistent with respect to postbacks.  

Session variables would do the trick, except that, if you right click on a link in the site and say open in new window, that window shares session variables with the one that is already open.

How do I either
(1) make it so that session variables are not shared with the case given above or
(2) use some other mechanism to have persistent variables with respect to postbacks?

Here's some stuff I tried...
I tried using server variables (request.servervariables) as it looked like it might do the trick, but it's read-only.  I also tried the me.RegisterHiddenField but it doesn't appear to be persistent across postbacks (when I do me.findcontrol, it doesn't find it after a postback)

Thanks in advance!
Who is Participating?
thrill_houseConnect With a Mentor Commented:
Just use viewstate, it's very similar to the session, except the information is stored on the client instead of the server.

viewstate is pretty much the same thing as storing information in an invisible label.

viewstate("var") = 1
viewstate('var2") = 2

Then I can just reference viewstate("var") as long as I am on a page, regardless of postbacks.  However, once you leave the page, the viewstate is lost.
stev0931Author Commented:
I should mention: one not very good solution is to have an invisible label control on the web form and use the text of the label to store the variable, but I'm hoping to find a better solution than this...
you could use the web.config file I think I have read somewhere, where you add a key and thus it keeps it value until changes or deleted, similar to the way you can store connection strings in there.
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

here I have got this to work, so basically you use the appsettings

    <add key="Variable" value="Test"/>

here is how I manipulate

        string[] value = ConfigurationManager.AppSettings.GetValues("Variable");
        ConfigurationManager.AppSettings.Set("Variable", "This");

I am thinking though you would have to use a unique key with each user as this is site wide. I THINK....
stev0931Author Commented:
Your suggestion, if I understand correctly, works with variables at an application level.  I need to work with variables at a page level.  So, I will have the same problem (and probably more problems) using web.config variables above as I would with session variables.

Do you have any thoughts on how I can get variables at the page level that will be persistent through postbacks?
stev0931Author Commented:
To be more clear, each Browser Window needs to have a unique mapping to the variable.  Session variables are almost what I need, in that you have a unique mapping to every browser until you start opening up new windows from inside the site.
Bob LearnedCommented:
1) How many variables are you talking about?

2) What kind of information is being stored?  Basically, is it a large amount of information?

Bob LearnedConnect With a Mentor Commented:
I wouldn't use ViewState if (a) you have a large number of variables, or (b) you have a small number of variables, but you are storing a large amount of data.  The page growth is exponential when you use ViewState, which can greatly affect the performance of the page.

stev0931Author Commented:
My current design calls for up to 100-500 variables per window with each variable containing no more than a few characters of data in a string

If necessary, I can make it so that the number of variables per browser is small (maybe a dozen or so), but doing this will likely result in the amount of data per variable increasing

It would be optimal to be able to support arbitrary data types, but just strings would be fine at this point

Bob, would you suggest using viewstate under these circumstances?  Or would you suggest something else?

And thank you all for your help!  It is most appreciated!
matt3ewConnect With a Mentor Commented:
You can use ViewState in your codebehind file. for example:
add to your codebehind file within the Partial Class:

Public Property MyTestValue() As String
        Dim o As Object = ViewState("Test")
        If o Is Nothing Then
            Return String.Empty
            Return ViewState("Test")
        End If
    End Get
    Set(ByVal value As String)
        ViewState("Test") = value
    End Set
End Property

Now you have page property which will only be persistant within the current page. To access its value simple call it like a standard property. for example:

Protected sub PageLoad ...
end sub

or Protected Sub myBtn_Click ...
MyTestValue = txtBox1.Text
end sub

Sry, a little behind in the posting...
Bob LearnedConnect With a Mentor Commented:
There is only one way to be really sure.  Store the values in the ViewState, then <View source> from the browser, and look how large the ViewState is.  If you can't tell a poor response from the ViewState, you might be OK.  Just remember that ViewState is a UTF-16 XML document encoded as Base-64, so anything like storing a DataSet with 1000 records in a DataTable, will push the ViewState way beyond a respectable limit.  

Another option beyond ViewState, is to store it in the Cache, with a key for each page.  This way it will be stored on the client, and not on the server.

stev0931Author Commented:
How would I " it in the cache, with a key for each page..."?
Bob LearnedConnect With a Mentor Commented:

Take Advantage of ASP.NET 2.0's Data Caching Techniques, Part 2

The simplest approach uses the key name directly, though—as with the Session and Application objects—you should cast the returned value back to the correct data type:

   Cache("key-name") = value-to-cache
   retrieved-value = CType(Cache("key-name"), object-type)

stev0931Author Commented:
Thanks for all the help!  The cache thing won't work, since it has the same problem as session, but viewstate solves the problem nicely.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.