Newbie -Public Variables Initialization & Scope

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

In .net when and how are public variables initialized - for each new user
session or for the application as awhole? Do all users get the same info in
public variables? If a userA signs on and public variables are set to
values, when userB signs on, does he get a different set of public variables
unique to him?

I am using public variables to pass info to different modules or projects
within the same solution. However each user will have different values. Am
I in big trouble? If so is there something else I can use? I didn't want to
use session variables, but maybe I should.

Thanks fo any help I can get.
 
Everything in a module is static (Shared). If you use classes instead, you
will not have this problem.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.
 
Thanks Kevin for the quick reply.

I forgot to say this is a Web program, Not Windows. Does it make a
difference?
 
I forgot to say this is a Web program, Not Windows. Does it make a
difference?
Click to expand...

None whatsoever.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.
 
Kevin,

Thanks again, but I just wanted to make sure I am getting this because I am
going to have to make major changes to an up & running web program ASAP and
pull an all weekender.

Example to help me explain and understand.
UserA logs on & he is has a miminal membership. He can only get certain
items. I store MIN in a public variable called gvmembertype. It has been
declared in a module. I need this info across pages & in a separate project
in the same solution. I will use it to control what userA sees. In the
meantime, UserB logs on and he has a Max membership. I store MAX in the
public variable gvmembertype.

1. Does this mean that ithe public variable now contains MAX and now both
users will see whateve MAX lets them, that the public variable set by User A
has have been overwritten. Is this correct?

2. Is there is only one public variable set and every different user
instance gets the same public variable info, rather than a unique set. Can
they can end up overwritting each other endlessly and every users will always
get only the last info in the public variable.


Thanks again,
This has not been happening that I can tell. Have I just been incredibly
lucky?
 
Well, your use of terminology indicates a lack of understanding about what
it refers to. In fact, there is no such thing as a "public variable." There
are public fields, and public properties. A field is probably the closest
thing to a variable, but it is a class member, not a variable. It behaves
like a variable, but has additional attributes, such as configurable scope
and accessibility. A property is actually 1 or 2 methods ( a "getter" and/or
a "setter") which are treated as if they are parts of a single field.

But again, the scope (visiblity or accessibility) of these things are
determined not only by the Access modifier (public, private, protected,
etc), but also by any other modifier that is applied, such as static
("Shared" in VB). An in VB.Net, the mix is even more confusing by the
existence of Modules, where everything is, without explicit definition,
static ("Shared").Modules are bad medicine, a bone thrown to VB6 developers
to prevent them from being too uncomfortable with the new OOP paradigm. But
IMHO, they cause more trouble than they solve, since the developer doesn't
have to explicitly declare anything in a Module as Shared or static.

The difference between Static (Shared) fields and properties, and Instance
fields and properties is that there is only one single instance of a static
field, property, class or method in a given application. It is "shared" or
used by every entity to which it is visible. An instance member does not
exist until an instance of a class is created, and there is one instance per
class created. This means that instance members are used explicitly and
separately from one another, and there can be many of them.

Please forgive me for not simply answering your question, but trying to help
you understand the mechanics behind it. I'm happy to explain as much as I
can to you, without simply giving you a solution. This way, once you "get
it" you will have a greater ability to solve similar problems in the future,
and use these tools more effectively.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.
 
Thanks for an excellent tutorial. I really appreciate it. I did come from
the VB 6 environment which had public/ global variables.

I declared these in a .net module as "Public gvariablename as string". (
never mentioned static or shared ) I read a .net book that said "public"
variables s was a way of passing information between pages. I did not
realize that the last user overwrote them, so that all users go whatever was
last put in the variable, rather than what they put in. I did some testing
to show this.

Again Thanks.
 
My pleasure! You're very welcome!

Again, remember that it's best to avoid using Modules. They can be
confusing, as under the hood, they are actually classes which the compiler
treats in a special way to make everything in them static (Shared). It's
better to get familiar with classes, encapsulation, and all the other OOP
benefits. After a short while, it will be second nature to you.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.
 
Thanks again Kevin. One more question (I hope).


Although I was hoping to avoid them, you inspired me and I have been
experimenting with classes and went thru some walkthoroughs. I can create
them and "get & set" info into and from them. However can only do it in one
VB procedure.

My program consists of several Web pages . What I really want to do is have
information that I get earlier in various Web pages that are being
processed with VB , available several pages later, where I need the pieces of
info to do final processing.

Should I be using session variables or can I use a class to save
information earlier during the processing of some pages and retrieve it
later? If so how do I get it later when I need it? Can I declare a new class
instance so that iitis available from any page processing?

If you know any good books or articles, I would be happy to read them.

Thanks you have been very helpful and patient.
 
Hi Dega,
Although I was hoping to avoid them, you inspired me and I have been
experimenting with classes and went thru some walkthoroughs.
Click to expand...

Good for you! You'll be glad you did. The hardest step is the first.
I can create
them and "get & set" info into and from them. However can only do it in
one
VB procedure.
Click to expand...

I'm not sure what you mean by this.
My program consists of several Web pages . What I really want to do is
have
information that I get earlier in various Web pages that are being
processed with VB , available several pages later, where I need the pieces
of
info to do final processing.

Should I be using session variables or can I use a class to save
information earlier during the processing of some pages and retrieve it
later? If so how do I get it later when I need it? Can I declare a new
class
instance so that iitis available from any page processing?
Click to expand...

Okay, we have a couple of issues here to clarify. First, I didn't know that
you're working with an ASP.Net application. This is a complicated
application to work on, because ASP.Net is about a client-server app hosted
on an HTTP web server. HTTP is stateless, and is a Request/Response
protocol. Let me explain a bit first:

A web client (such as a browser) makes an HTTP request for a "resource" to a
web server. The server responds by finding the resource and returning it to
the client. The server remembers nothing after that. The next request from
the same client is therefore a brand new request. The server doesn't
remember the previous one.

ASP.Net is a framework designed to act as an application that is hosted by a
web server. Unlike the web server, it does have persistent memory, but is
designed to work in the HTTP environment. It has an application memory,
which is not client-specific, but is available to any class instance in the
application. It also has Session memory, a Collection it maintains where it
can remember some data about each client that has recently sent a Request.
Because of the stateless nature of HTTP, there is no way for a client to
"disconnect" from the application, no way for the application to know which
Request will be the last from any client. Therefore, in order to prevent
memory from building up until ti runs out, the Session times out 20 minutes
after the last Request from any client. Remember, this is a client-server
app, which may have many clients, each of which will require some server
resources. Therefore, keeping memory limited is the only way to go.

Again, because of the HTTP environment, and the fact that any given page is
not likely to be requested repeatedly, that is, the client will request
various pages at will, the Page class created when a Request comes in is not
persisted in memory. The class is instantiated when the Request is received,
lives for the duration of the processing of the Request, and then destroyed
when the Response is sent.

How a Page retains its state is managed by a rather complex framework of
tricks. The most important of these is ViewState. An HTML Form can post data
to the server with its Request. This is why an ASP.Net Page class is always
hosted in a WebForm. When the page is sent to the client, it contains both
JavaScript and hidden form fields that are used on the client to prepare
information about the state of the HTML document on the client which can be
posted back to the server. This way, the page's Form Post can "remind" the
server about what state the HTML document on the client was in when it
posted back. Then, the server-side application re-creates the Page class,
and restores it to the current client state for processing.

What this means is that, while it may seem like it is the same Page class
instance on the server with each PostBack, it is a new instance every time.
In essence, each instance is a "restoration" of the previous instance. That
is why the class doesn't seem to persist its memory state.

Static (Shared) classes and class members are different, in that there is
only 1 instance in the Application, and because of this, it can remain in
Application memory for the lifetime of the application. However, as there is
only 1 instance, it is used ("shared") by all clients. Anything one client
does to it is seen by any other client which accesses it. As you can see,
this is only useful if the data is not client-specific.

So, you have several alternative ways of persisting and restoring
client-specific data in your Page class, and those alternatives are the same
ones that ASP.Net has for its application. That is, you can use Page
ViewState, Session state, or a database. These are the most common ways.
Whenever possible, avoid Session state, as again, this requires duplicate
memory on the server for each client. If I give you a dollar, you have only
received 1 dollar. But if a million people each give you a dollar, you have
received 1 million dollars.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.
 
Kevin, you have been very helpful, knowledgeable and patient. Thank you.

I am doing a Web app using asp.net and vb.net. I am not new to
programming, but I am new to .net. I am going to use session variables. The
information is unique to each user, but It is not voluminous. I need about 5
variables per user & each is 1-3 bytes. Also the population is somewhat
limited. When I have more time I will experiment with other ways, but this
will get me where I need to be. Again thank you.
 
Back
Top