Every time your page posts back it reloads the Page class. Take a look at
the code you have just under your Class declaration:
The New constructor creates a new empty instance of a class. That is why
your ListItemCollection is empty. You made it empty.
Of course, unless you re-create the ListItemCollection with every PostBack,
it won't exist. Leaving off the "New" won't help, as the variable will be
uninitialized. So, the first thing to do would be to remove the "New" from
your variable declaration. You need to figure out where and how to
initialize it. It needs to be declared (Dimmed). But how you initialize it,
persist it, and add items to it is where your problem is.
Your question Title indicates that you have some understanding of the
problem. But be careful of the word "global." That is an word which can mean
any of a number of things. The term "global" refers to the "scope" of a
variable. In an ASP.Net application, variables can have a wide variety of
scopes, and a fairly large number of "global" scopes. A variable can be
global to a page, to a class in a page, to an Assembly, to a User Session,
or to the entire web application. What we need to do is identify the proper
scope of your variable, and find the appropriate mechanism for making it
As this variable is page-specific, and you have declared it as a private
field in the Page class, it is already global to the Page. But what you need
to do is either rebuild it with every PostBack, or persist it somewhere.
There are several possibilites for this: ViewState and Session spring to
mind. ViewState is maintained by passing the data back and forth between
client and server.On the server it represents a "StateBag" type of
Collection, similar to a Dictionary object. If you want to store your
Collection in ViewState, the easiest thing for you to do with it would be to
store it in an ArrayList or HashTable, which can easily and automatically be
serialized into ViewState.
You can also store it in Session State. However, be careful about using
Session State. It can time out and disappear after a (default) 20-minute
interval of inactivity on the part of the client. In addition, Session State
is global to all pages of a user's Session, and you may run into
complications with other data in Session State, as well as memory issues
(there is a separate Session memory space for every client on the server, so
the amount that you store in Session is multiplied by the number of
concurrent User Sessions).
Neither a follower nor a lender be.
"Joseph George" <com> wrote in message