Variable not incrementing

[Mark A. Sam]

Hello,

I am using Visual Web Developer and decared a Public Variable in the Class
section. I assigned a value in the load section, and on a button I set it
up to increment, but it always delivers the same value, 1. When I increment
the variable from the button, shouldn't it hold the new value? I also
tried declaring the variable as a Friend, but it wasn't any more friendly.


Partial Class test

Inherits System.Web.UI.Page

Public i As Integer

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
Handles Me.Load

i = 0

End Sub

Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click

i = i + 1

MsgBox(i, MsgBoxStyle.Information)

End Sub

End Class

 

[Marina Levit [MVP]]

HTTP is stateless. This means on every request to the server, a new Page
object is created. Since it is always a new object, whatever values you set
on the old object, will not persist.

However, even if everything worked as you imagine with there being one
instance of a Page object all the time, your code would still not run as
expected. This is because you are always setting i to 0 in Page_Load. So
after the user clicks the button, i would be set to 0, then incremented by 1
in the click handler. Then on the next click the same thing would happen,
and i would always be at 1.

However, even if you fix your code to only set it to 0 in Page_Load when
it's not a postback (or just not do anything, since 0 is the default for an
integer anyway), your code would not work as you expect for the reasons
given in the beginning of the post.

I recommend you get a book on ASP.NET and do some reading about how it all
works before proceeding much further. Without an understand of the page
lifecycle and the basic mechanics of ASP.NET it will be hard to get far.

 

[Scott M.]

But you must remember that in the client/server model of the web, each time
you request this web page, a BRAND NEW instance of this class is created and
your variable is created again, from scratch. You aren't continuing with
the same page class instance the second time you use the page.

You must store your variable in a more persistant location, such as a
cookie, the cache, viewstate or a database to be able to reuse it across
page calls.

 

[Mark A. Sam]

Thank you Marina. You are right about not understanding what is happening.
Here is why I am not following. I placed a textbox on the same form using
the same button, and was able to increment the value in the textbox. The
code is below:
Partial Class test
Inherits System.Web.UI.Page

Public i As Integer

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
Handles Me.Load

'i = 0

End Sub

Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click

'i = i + 1

'MsgBox(i, MsgBoxStyle.Information)

TextBox1.Text = TextBox1.Text + 1

End Sub

End Class


If the page refreshes each time I click the button, then why doesn't the
textbox lose its value? Maybe I'm not making sense, but its how I see it.


God Bless,

Mark

 

[Scott M.]

That's because Textboxes (as well as many of the Web Forms Controls)
maintain their own state like this:

When data is posted to the server, that data becomes the DEFAULT value of
the control as it is sent back down to the browser. Now, when the browser
sends that data back up to the server, the server uses this data as the
starting point from which to work. No data is actually being stored
(persisted) on the server.

A good analogy of how client/server works:

When you look up at the stars at night, you are seeing what they looked like
in the past. For all you know, the star you are looking at doesn't even
exist anymore.

When you look at a web page (nice segway, huh?), you are seeing the RESULTS
of some server processing, but by the time you see those results, the server
has disconnected from you and moved on to handle someone else's request.
None of your data is stored on the server. If you re-submit the page you
are looking at in your browser, the server must create a brand new instance
of a page class, place band new instances of controls on this page and
attempt to restore certain controls back to their previous values. Of
course, the server doesn't have any of these previous values, so it is up to
the client to post those values up to the server. That's what's happening
with your textbox example.

The ONLY way to persist data on the server is to store that data somewhere
that the server can get a hold of it. As I mentioned in my last reply:
ViewState, the Cache, a database, cookies, a flat file, etc. are all good
candidates.

As Marina suggested, a good understanding of client/server communication as
well as a good understanding of the Page class's life-cycle would be a good
place to start.

Good luck,

Scott

 

[Mark A. Sam]

Hello Scott,

I understand what you are saying, but I don't understand why this is any
different than using Access VBA or another language in a client server
setting. If the data doesn't persist on the server, it is becuase noone
addressed that issue? I have an analogy about visual studio... It is like
putting a Peterbilt body, a Cummins engine, and an Eaton Transmission onto a
horse drawn wagon. Why not rebuild the chassis while you're (meaning
Microsoft) at it.

God Bless,

Mark

 

[Scott M.]

To address your questions/comments.

HTTP client/server is not at all how programming Access with VBA works.
Access VBA programs are client only, not client/server (unless you put the
Access DB on a shared server, in which case it is client/server, but not
HTTP client/server - so the comparison is still not valid).

As for data not persisting on the server, it is not Visual Studio or
Microsoft's fault, this is the very nature of HTTP and the WWW. This is by
design and is not a glitch or a bug. It is to facilitate the hundreds of
millions of clients out there connecting to the (somewhat smaller by
comparison) millions of servers out there. A server just can't keep a
dedicated connection open to each client that wants it. If it did, then
we'd all be getting "busy signals" quite often when we try to visit any web
site.

In short, HTTP client/server is just a different architecture than client
only because of the distributed nature of the Internet. Putting an Access
VBA application on a server doesn't make that architecture client/server in
the same sense because each client DOES have a continuous connection to the
server (and tying up precious resources as well). Imagine if 1,000 (just to
use a very small number for demonstration purposes) people tried to get at
your VBA application at the same time. How about 1,000,000? Wouldn't it
make sense to only be connected to the user for just the time it takes to
process their request, and free up the database for someone else to use?

If you are going to do any web development at all (Microsoft .NET, Java
Server Pages, PHP, etc.) you must understand this concept well and also
understand that it is not something brought on by a vendor, it is the way
web development works regardless of platform or product.

Good luck,

-Scott

 

[Mark A. Sam]

Scott,

I'm not trying to give you hard time by disagreeing with you, but I do.
I understand what you are saying about the nature of http and www, but I
believe that the internet can be exactly like a client server on a computer
network. If that is what Bill Gates wanted that is what would happen. Bill
runs the show. If he wanted to change the protocols of the internet and how
his browser worked, he could do it. For the most part, millions of people
don't concurrently access the bulk of websites. Maybe hundreds would be a
high number, so servers could in most cases handle the traffic. I think its
a matter of design. I have linked SQL Server tables to Access apps, on my
local machine, to a server in Atlanta, so I know the technology is there.
Its just a matter of "doing it right", which unfortunately is a Microsoft
weakpoint. It always falls short of the mark in all of its apps.

But that is just my opinion and I know it will anger a lot of Microsoft
devotees and I'm sorry for that.

God Bless,

Mark

 

[Scott M.]

Mark,

You are entitled to your opinion, but what we are discussing here isn't
opinion based.

FACT: The Internet and the World Wide Web are not goverened by Microsoft.
If anything, it is goverened by The World Wide Web Consortium. When software
manufacturers wish to use the Internet in a different way, they make
different software. Instant Messaging is a good example of this. When you
use an instant messanger product (from AOL, MS, Yahoo, or anyone else), your
message is travelling over the Internet, but NOT via HTTP. And, because
different software manufacturers come up with their own protocols that are
proprietary, you run into compatibility issues between software. Try IM-ing
a MSN Messanger user via AOL's AIM - not going to happen! On the other hand
you can use different email software clients to send/recieve email because
email (all email) travels using the mailto: protocol - - it's a standard.

FACT: HTTP is the Internet's web server protocol. HTTP was not invented,
nor is it goverened by any software manufacturer. It is a standard protocol
that the WWW is designed to run on. You can't just up and change it or the
WWW would collapse.

Now, to address your specific comments...see inline below:

Scott,

I'm not trying to give you hard time by disagreeing with you, but I do.
I understand what you are saying about the nature of http and www, but I
believe that the internet can be exactly like a client server on a
computer network.

On who's network? Would that network run NETBIOS, NETBUI or some other
protocol? And what if one application on one network wanted to communicate
with another application on another network, but the two networks run on
different protocols?

What you are suggesting would only be possible if there were standard
protocols that everyone's software understood and only if the network could
support millions of simultaneous connections. Perhaps one day, but not
today.

If that is what Bill Gates wanted that is what would happen. Bill runs
the show. If he wanted to change the protocols of the internet and how
his browser worked, he could do it.

ROFLMAO: I'm sorry, but a statement like this just tells me that you really
don't have an understanding of how things *actually* work. There are
countless initives that Bill and MS pushed hard over the years, that wound
up in the garbage because the rest of the world didn't agree. Can you say
"MS Bob"?

For the most part, millions of people don't concurrently access the bulk
of websites. Maybe hundreds would be a high number, so servers could in
most cases handle the traffic.

What source do you get this information from? I'd say that is flat out not
true at all. And, even if it were true, many (millions...not hundreds)
sites DO experience millions of hits per day. So, shouldn't the network be
set up in a way that can handle the highest possible volumne, not the
lowest?

I think its a matter of design.

Yes. You are 100% absolutlely correct. The Internet was absolutley designed
like this intentionally and it works quite well. Just because you have to
change your client programming mentality doesn't make HTTP client/server bad
or wrong...just different.

I have linked SQL Server tables to Access apps, on my local machine, to a
server in Atlanta, so I know the technology is there.

And, what was the highest volume your applicaiton ever had to deal with?
With this, I think you've hit the nail on the head. No one is saying that
*all* applications must be HTTP based. In your situation, you found a
solution that worked for you. It's just that on the world's largest
network, that isn't how things are done. The network MUST be able to handle
extremely high volumes of traffic that come from different platforms and
from different software. That design specification can only mandate one
thing: STANDARDS. HTTP is that standard.

Its just a matter of "doing it right", which unfortunately is a Microsoft
weakpoint. It always falls short of the mark in all of its apps.

Again, I fail to understand why you are blaming Microsoft for something that
wasn't designed, built or tested by anyone from MS. In fact, the Internet
and its fundamental protocol, TCP/IP, was created before there even was a
Microsoft (mid 1960's by the Defense Advanced Research Projects Agency or
DARPA). The WWW was created by Tim Berners-Lee, who is now the President of
the World Wide Web Consortium (which is not accountable to any software
vendor).

But that is just my opinion and I know it will anger a lot of Microsoft
devotees and I'm sorry for that.

It's not a matter of angering any MS devotees. It's a matter of you not
understanding how the system is built or who built it as well as how and
why it was built that way. That's not my opinion. Based on your
statements, it is clear that you need to go back and try to understand the
very nature of the Internet before you apply non-truths to it.

Good luck,

-Scott

 

[Mark A. Sam]

Hello Scott,

I don't want to drag this on. I understand your point of view and believe
what you say about the current state of the internet. I respect your
knowledge and ability and you are right, I don't understand the workings,
but I do believe they can be improved. Of course I'm a guy that thinks
evolution is silly nonsense.

Thank you for your response.

God Bless,

Mark

 

[Scott M.]

I would just say that before you can improve something, shouldn't you
understand what it is and what it does in the first place, though?

I hear what you are saying and, please understand that I mean no disrespect.
But, if you understood how and why the Internet works as it does, you might
come to the realization that it works just fine the way it is and that the
*stateless* nature of the web isn't a drawback or something to be solved.

Just keep an open mind as you investigate.

Good luck!

-Scott