Strange Behaviour

[Wayne Wengert]

I have a set of aspx pages created using VSNET 2003/VB. The web site
includes a java based menu. For a specific selection I need to change the
value of a variable in a common class. I set the menu app to call a special
aspx page whose only purpose is to set the class variable and then transfer
to the main aspx page. The initial page originally had only the following
code:
============================================
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
CommonClass.strCallFrom = "User"

Server.Transfer("frmFindBand.aspx")

End Sub

=========================================================

That does not work - the CommonClass.strCallFrom variable is not getting
set? Any ideas as to why this is failing?



TIA



Wayne

 

[Kumar Reddi]

Is the strCallFrom is a static variable or instance variable? If its not
static variable, I do not see any code to instantiate the CommonClass
object???

 

[Eliyahu Goldin]

Wayne,

Welcome to the web development world. Once you leave a page, it doesn't
exist anymore. Neither there is CommonClass instance, unless you took
special care to make it persistent. You should save the variable in one of a
few persistent storages, for example in a session variable.

Eliyahu

 

[Eliyahu Goldin]

Note that static variables have application scope as opposed to session.
That means the two sessions while overwrite each other setting.

Eliyahu

 

[Wayne Wengert]

Thanks for the replies guys but I really don't understand the need to
instance the class? If I add a button to the page and issue the transfer
from the click event, things work fine? What is different (I will readily
admit that I have a poor grasp of OO)?

Throughout the other 20+ pages I regularly set a CommonClass variable and
then use it in another page. I thought that was the whole idea of a common
class?

Any education is much appreciated.

Wayne

 

[Scott Allen]

You won't see a problem until there are simultaneous user's making
requests to your web application. You are using a single location to
store a piece of data for all users. Their requests will start
overwriting this single location with data for each request. Depending
on the timing user A could get user B's results or user B might get
user A's results.

It's always good to keep request state as close to the request as
possible. Don't try to take shortcuts by sticking a piece of data in a
common class and hope that when something later happens it still finds
the data there.

The Context.Items collection is a good place to store the information
you need to carry around.

 

[Wayne Wengert]

Scott;

Thanks for the information. I think I am beginning to see my error here. The
Common Class information exists once for my application and if User A sets a
value in variable "X", any user asking for that variable will get that new
value? This was my first attempt at using a common class and I think I went
way overboard. I'll go back and change all use of the common class variables
to Session objects instead and just use the common class for constant values
like connection strings. Does that sound right?

Wayne

 

[Scott Allen]

Hi Wayne:

Yes, that's what can happen with Shared fields in VB.NET.

Like I say, Context.Items can be just as useful as Session if you need
information to stick around during a Server.Transfer