471,338 Members | 1,308 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,338 software developers and data experts.

simple global variables question

hi, i have a very simple html page with a global variable, a function
to increment its value, and a form that calls the function. however,
what happens is that every time i click the image, the page is
reloaded, and the value is reset to 1. is this what i should be
expecting? are global variables not persistent across reloads? if
this is the case, how can i set it up so that clicking the button
doesn't reload the page automatically, but rather just calls the
function. this is so frusterating :(
<html>
<head>
<script language="javascript">

var a=1;

function incValue()
{
a = a+5;
}

</script>
</head>

<body>

<form>
<input type="image" src="one.gif" onclick="incValue()"/>
</form>
</body>
</html>

Jul 23 '05 #1
13 1594
lost hope wrote:

(snip)
...are global variables not persistent across reloads?
Nope. http is stateless, reload or not.
if this is the case, how can i set it up so that clicking the button
doesn't reload the page automatically, but rather just calls the
function. this is so frusterating :(


(snip)

<input type="image"> is a graphical submit button. To avoid form
submission and the loading of a new document, try:

<a href="#" onclick="return incValue()"><img src="one.gif" /></a>

var a = 1;
//watch that title bar !
document.title = 'a = ' + a;
function incValue()
{
a += 5;
document.title = 'a = ' + a;
return false; //kill link default
}

Jul 23 '05 #2
"RobB" <fe******@hotmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...
lost hope wrote:

(snip)
...are global variables not persistent across reloads?


Nope. http is stateless, reload or not.
if this is the case, how can i set it up so that clicking the button
doesn't reload the page automatically, but rather just calls the
function. this is so frusterating :(


(snip)

<input type="image"> is a graphical submit button. To avoid form
submission and the loading of a new document, try:

<a href="#" onclick="return incValue()"><img src="one.gif" /></a>

var a = 1;
//watch that title bar !
document.title = 'a = ' + a;
function incValue()
{
a += 5;
document.title = 'a = ' + a;
return false; //kill link default
}


For me, just using <img src="image.gif" onclick="incValue()"> has worked.
The image isn't a link or form input, but it still responds to "onclick". I
don't know if it works in browsers other than IE, though.
Jul 23 '05 #3
Tony wrote:
"RobB" <fe******@hotmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...
lost hope wrote:

(snip)
...are global variables not persistent across reloads?
Nope. http is stateless, reload or not.
if this is the case, how can i set it up so that clicking the button doesn't reload the page automatically, but rather just calls the
function. this is so frusterating :(


(snip)

<input type="image"> is a graphical submit button. To avoid form
submission and the loading of a new document, try:

<a href="#" onclick="return incValue()"><img src="one.gif" /></a>

var a = 1;
//watch that title bar !
document.title = 'a = ' + a;
function incValue()
{
a += 5;
document.title = 'a = ' + a;
return false; //kill link default
}


For me, just using <img src="image.gif" onclick="incValue()"> has

worked. The image isn't a link or form input, but it still responds to "onclick". I don't know if it works in browsers other than IE, though.


That's ok, Image objects have onclick handlers too, in almost all
current browsers. Probably not a good habit to get into, however, as
they won't be spidered as links are. Add style="cursor:pointer;" for a
more link-like appearance.

Jul 23 '05 #4
RobB wrote:
Tony wrote:
RobB wrote: <snip>
<a href="#" onclick="return incValue()"> ...
<snip> For me, just using <img src="image.gif" onclick="incValue()">
has worked. The image isn't a link or form input, but it
still responds to "onclick". I don't know if it works in
browsers other than IE, though.


That's ok, Image objects have onclick handlers too, in almost
all current browsers. Probably not a good habit to get into,
however, as they won't be spidered as links are. Add
style="cursor:pointer;" for a more link-like appearance.


It is difficult to see what benefits can follow from having href="#"
spidered. What is lost when an onclick handler is used with an image is
any potential built into the browser for the use of an input device that
is not a 'pointing device' (such as a mouse). Denying the possibility of
using a keyboard for input (besides inconveniencing those that use
keyboards for input habitually) would mean that the result failed to be
accessible, and so would be illegal in some contexts throughout the
world (and antisocial in the rest). Although it would be possible to
implement the keyboard-based operation of the site within the script,
but that is a lot of additional work just to reproduce what browsers can
otherwise do for you (and even more complex to achieve reliably
cross-browser).

Richard.
Jul 23 '05 #5
lost hope wrote:
hi, i have a very simple html page with a global variable, a function
to increment its value, and a form that calls the function. however,
what happens is that every time i click the image, the page is
reloaded, and the value is reset to 1. is this what i should be
expecting? are global variables not persistent across reloads? if
this is the case, how can i set it up so that clicking the button
doesn't reload the page automatically, but rather just calls the
function. this is so frusterating :(
<html>
<head>
<script language="javascript">

var a=1;

function incValue()
{
a = a+5;
}

</script>
</head>

<body>

<form>
<input type="image" src="one.gif" onclick="incValue()"/>
</form>
</body>
</html>


If all you are using it for is to create a clickable image, just have
the input on its own with no form - then there's no form to submit
and no href to follow.

Users without JavaScript may wonder what the image is supposed to do
since they will see a pointer cursor when hovering over it, but
nothing will happen when they click.
--
Rob
Jul 23 '05 #6
Richard Cornford wrote:
RobB wrote:
Tony wrote:
RobB wrote: <snip> <a href="#" onclick="return incValue()"> ... <snip> For me, just using <img src="image.gif" onclick="incValue()">
has worked. The image isn't a link or form input, but it
still responds to "onclick". I don't know if it works in
browsers other than IE, though.
That's ok, Image objects have onclick handlers too, in almost
all current browsers. Probably not a good habit to get into,
however, as they won't be spidered as links are. Add
style="cursor:pointer;" for a more link-like appearance.


It is difficult to see what benefits can follow from having href="#"
spidered.


Hmm...didn't I say -

"Probably not a good habit to get into..."

....signifying that it was the *practice* of using image onclicks that
was being commented on, not the (trivial) example at hand. Certainly
agree about input devices; as well, all possibility of a default
alternative for JS-disabled users is removed - again, meaningless for
the above but worthy of thought as a general rule.

(snip)
Denying the possibility of using a keyboard for input...
would be illegal in some contexts throughout the world [ .. ]


Are there people doing time for Image.onclick? #:=0

Jul 23 '05 #7
hey guys,
thanks for all your help -- everything is much clearer now =) i
figured global state wasn't persistent across page reloads, but i
couldn't see why clicking the input (of type image) was causing the
refresh. now i understand. yay!

Jul 23 '05 #8

"RobB" <fe******@hotmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
Tony wrote:

For me, just using <img src="image.gif" onclick="incValue()"> has

worked.
The image isn't a link or form input, but it still responds to

"onclick". I
don't know if it works in browsers other than IE, though.


That's ok, Image objects have onclick handlers too, in almost all
current browsers. Probably not a good habit to get into, however, as
they won't be spidered as links are. Add style="cursor:pointer;" for a
more link-like appearance.


I didn't get the impression that this was something that needed to be
spidered, but that is a good point to remember.
Jul 23 '05 #9
"RobB" <fe******@hotmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
Richard Cornford wrote:

"Probably not a good habit to get into..."

...signifying that it was the *practice* of using image onclicks that
was being commented on, not the (trivial) example at hand. Certainly
agree about input devices; as well, all possibility of a default
alternative for JS-disabled users is removed - again, meaningless for
the above but worthy of thought as a general rule.
Didn't think about that :0
(snip)
Denying the possibility of using a keyboard for input...
would be illegal in some contexts throughout the world [ .. ]


Are there people doing time for Image.onclick? #:=0


Damn! I better start changing my code before they come breaking in my front
door to haul me off!
Jul 23 '05 #10
JRS: In article <d4******************@news.demon.co.uk>, dated Thu, 28
Apr 2005 06:58:13, seen in news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted :
What is lost when an onclick handler is used with an image is
any potential built into the browser for the use of an input device that
is not a 'pointing device' (such as a mouse). Denying the possibility of
using a keyboard for input (besides inconveniencing those that use
keyboards for input habitually) would mean that the result failed to be
accessible, and so would be illegal in some contexts throughout the
world (and antisocial in the rest). Although it would be possible to
implement the keyboard-based operation of the site within the script,
but that is a lot of additional work just to reproduce what browsers can
otherwise do for you (and even more complex to achieve reliably
cross-browser).


Not necessarily, as far as I can see.

If the "mouse" is the only way of getting the effect that onClick
provides, then indeed those without a "mouse" may be improperly
handicapped.

But if the site is designed so that the onClick effect can be obtained
independently of the image and without a "mouse", then ISTM perfectly
reasonable to add another way to get the effect, using "mouse" and
onClick, to the advantage of those who can use it.

And the clickable image may be a positive advantage for those who can
use a pointing device but not a keyboard.
After all, although our Public Library does stock large-print books, it
also stocks rather more ordinary books which not everybody can read.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 23 '05 #11
Dr John Stockton wrote:
Richard Cornford posted :
What is lost when an onclick handler is used with an
image is any potential built into the browser for the
use of an input device that is not a 'pointing device'
(such as a mouse). ...
<snip> Not necessarily, as far as I can see.

If the "mouse" is the only way of getting the effect
that onClick provides, then indeed those without a
"mouse" may be improperly handicapped.
Whether a mouse is the only means of activating an onclick handler
depends a great deal on the HTML element on which the handler is set,
and a little on the browser that is being used. With the various
button-type elements, and A elements (or, pretty much any element that
can be navigated to with the tab key on the keyboard) the bulk of modern
browsers will fire the onclick event when the 'activating' action is
performed with the keyboard (be that hitting the return key, or
whatever).

The problem with an IMG element is that it is not a natural receiver of
focus, and so cannot be targeted by keyboard input events. Leaving the
programmer with the problem of intercepting keyboard input at a higher
level (say the document) and working out when, and what, input from the
keyboard should relate to the IMG. While warping the IMG in A, or using
a button-type element would allow the browser to do the work instead.
But if the site is designed so that the onClick effect can
be obtained independently of the image and without a "mouse",
then ISTM perfectly reasonable to add another way to get the
effect, using "mouse" and onClick, to the advantage of those
who can use it.

And the clickable image may be a positive advantage for those
who can use a pointing device but not a keyboard.
Yes, accessibility requires that the operation of the page be
independent of any particular input device, and you certainly wouldn't
achieve that by excluding the use of a mouse.
After all, although our Public Library does stock large-print
books, it also stocks rather more ordinary books which not
everybody can read.


I point out the possibility of alternative input devices because it is
common for individuals who use a particular method themselves to assume
that everybody else is just like them. An attitude that is manifest in
the common use of the phrase "click here". Accessibility is an area
where that attitude is particularly problematic, but in reality
diversity the behaviour of user's with regard to preferred input devices
is already considerable without even considering those who may have
special requirements.

Richard.
Jul 23 '05 #12
RobB wrote:
Richard Cornford wrote:

<snip>
Denying the possibility of using a keyboard for input...
would be illegal in some contexts throughout the world [ .. ]


Are there people doing time for Image.onclick? #:=0


All of the legislation that I am aware of uses financial penalties
rather than imprisonment (though those not paying their fines,
court-awarded damages, compensation, costs, etc, may become subject to
eventual imprisonment).

Richard.
Jul 23 '05 #13
JRS: In article <d5*******************@news.demon.co.uk>, dated Sat, 30
Apr 2005 22:21:26, seen in news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted :
Dr John Stockton wrote:
Richard Cornford posted :
What is lost when an onclick handler is used with an
image is any potential built into the browser for the
use of an input device that is not a 'pointing device'
(such as a mouse). ...

<snip>
Not necessarily, as far as I can see.

If the "mouse" is the only way of getting the effect
that onClick provides, then indeed those without a
"mouse" may be improperly handicapped.


Whether a mouse is the only means of activating an onclick handler
depends a great deal on the HTML element on which the handler is set,
and a little on the browser that is being used. With the various
button-type elements, and A elements (or, pretty much any element that
can be navigated to with the tab key on the keyboard) the bulk of modern
browsers will fire the onclick event when the 'activating' action is
performed with the keyboard (be that hitting the return key, or
whatever).


I wrote not "an onclick handler" but "the effect that onClick provides".

In some cases, one might provide a Button which calls the same function
as the image onClick.

If the onClick is used to supply X & Y co-ordinates, that might
otherwise be done by "<input type=text ...>".

There is, fortunately, no legal requirement to put all users on the same
footing by disabling the able; the requirement is that the less able
should not be unnecessarily disadvantaged.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Jul 23 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Tony Johansson | last post: by
4 posts views Thread by Geoff Cox | last post: by
24 posts views Thread by LP | last post: by
7 posts views Thread by Mark Prenter | last post: by
44 posts views Thread by fabio | last post: by
37 posts views Thread by eoindeb | last post: by
6 posts views Thread by Jim M | last post: by
10 posts views Thread by ma | last post: by
26 posts views Thread by optimistx | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.