By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,636 Members | 1,207 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,636 IT Pros & Developers. It's quick & easy.

On keypress event ... Can the bell be disabled?

P: n/a
You'd think this was an occasionally asked question, but a search for
previous related posts only turned up one from 1999, and that one was
never anwered. So...

When handling a keypress event, the terminal bell always rings (at
least with Internet Explorer). While it's not a show-stopper, it can
become annoying. Anyone have any tricks to silence the bell?

Thanks in advance!

-Dave H.

Sep 27 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a


Dave Hammond wrote:
When handling a keypress event, the terminal bell always rings (at
least with Internet Explorer). While it's not a show-stopper, it can
become annoying. Anyone have any tricks to silence the bell?


When you press a key with script disabled you get no bell but if you
have script with an onkeypress handler then you get a bell?
Never heard of that.
Have you tried to change some IE/Windows settings (no idea which ones
that would be)?
Do you have a URL where that effect could be visited?

--

Martin Honnen
http://JavaScript.FAQTs.com/
Sep 28 '05 #2

P: n/a
The application defines handlers for the Enter key and several Alt-x
key combinations. I know this is not kosher from a web development
purist's point of view, but the application is targetted at a corporate
data entry staff, and the key redefinition mimics a legacy application,
providing a vastly reduced learning curve.

Anyway, the Enter key normally doesn't beep, but after defining the
handler it now does. The Alt-x key combinations always beeped
(presumably because they have no native function).

Sep 28 '05 #3

P: n/a
Lee
Dave Hammond said:

... the application is targetted at a corporate
data entry staff, and the key redefinition mimics a legacy application,
providing a vastly reduced learning curve.


You're trading a learning curve for months of headaches.
It will never be quite the same as the legacy system.
Bite the bullet and allow them to learn to use a web interface.

Besides the problems you're having trying to pervert the browser
to look like something else, and the new problems that will arise
with each new browser version, it won't be long before your data
entry people begin to complain because the interface doesn't
behave they way they expect web applications to behave.

Sep 28 '05 #4

P: n/a
Dave Hammond wrote:
When handling a keypress event, the terminal bell always rings (at
least with Internet Explorer). While it's not a show-stopper, it can
become annoying. Anyone have any tricks to silence the bell?


Are the handlers navigating somewhere? If so, go to the Control Panel,
Sounds, and select [none] as the sound event for "Start Navigation".
That's all I can think of off-hand.

Luck!
Kev

Sep 28 '05 #5

P: n/a
Months of headaches? "Pervert" the browser? It sounds like you're
someone who has the luxury of telling his customers how he expects them
to work, and doesn't mind throwing their productivity out the window
for the sake of a design philosophy.

First, these are data entry operators: they get paid to enter as much
data as possible in as short a time span as possible. They're
experienced and extremely proficient at using the right hand to enter
numbers on the keypad and hit Enter to advance from field to field.
Their right hand never leaves the keypad, so their productivity is
maximized. Their left hand positions on the Alt key, ready to hit
whatever command key combination is required. If I changed their model
to a strict browser style, they'd be using the Tab key (or worse, the
mouse) to advance through the fields. They'd need both hands to enter
data, and the left hand would have to serve double duty for Tabbing
through the fields and entering commands. Their productivity would
drop like a stone. And, I'd probably be looking for a new job.

Second, I fail to see why using a documented part of the javascript API
is "perverting" anything. If the javascript API developers didn't
think being able to trap key press events was a good thing, then why
would they have spent the effort writing code to support it?

As for new problems arising with new browser versions: that's what
development cycles are for. If the API changes, then we modify our
applications accordingly. If a new browser version fails to adequately
support a well documented part of the API, then chances are very good
that it wouldn't make it on to our users desktops.

-Dave H.

Sep 29 '05 #6

P: n/a
Lee
Dave Hammond said:

Months of headaches? "Pervert" the browser? It sounds like you're
someone who has the luxury of telling his customers how he expects them
to work, and doesn't mind throwing their productivity out the window
for the sake of a design philosophy.
No, I'm somebody who's made the mistake that you're making.
Once. And have had enough sense since then to convince
anybody who wanted me to do it again that they were making
a mistake.

You will regret it. Do not try to make a browser behave
like something else.

First, these are data entry operators: they get paid to enter as much
data as possible in as short a time span as possible. They're
experienced and extremely proficient at using the right hand to enter
numbers on the keypad and hit Enter to advance from field to field.
Their right hand never leaves the keypad, so their productivity is
maximized. Their left hand positions on the Alt key, ready to hit
whatever command key combination is required. If I changed their model
to a strict browser style, they'd be using the Tab key (or worse, the
mouse) to advance through the fields. They'd need both hands to enter
data, and the left hand would have to serve double duty for Tabbing
through the fields and entering commands. Their productivity would
drop like a stone. And, I'd probably be looking for a new job.
If that's true (and I believe you're underestimating their
ability to adapt), then it is foolish to try to get them to
use a browser for this application. Do not try to make a
browser behave like something else.
Second, I fail to see why using a documented part of the javascript API
is "perverting" anything.
The fact that you are able to do something does not make it
reasonable to do it. There are many legitimate reasons for
capturing keypresses. Trying to make a browser behave like
something else is not one of them.
As for new problems arising with new browser versions: that's what
development cycles are for. If the API changes, then we modify our
applications accordingly. If a new browser version fails to adequately
support a well documented part of the API, then chances are very good
that it wouldn't make it on to our users desktops.


That's a good one. What do you do when a browser that doesn't
behave the way you expect it to behave is required by your users
for some other job function, and so your management tells you to
make it work? Probably wish you hadn't agreed to this mistake
in the first place.

Sep 29 '05 #7

P: n/a
Maybe I'm being dense, but what reason would you have to capture a
keypress, if not to "do something" when the key is pressed? Clearly,
the "something" could have been triggered by a mouse click, since that
is the native user interface for a browser. However, presumably, the
application developer felt that it made more sense to invoke the
functionality by key-press rather than mouse click. Whether to mimic a
legacy application or extend the user interface for some other reason,
what is the difference? You're still using the key press event
handler, and it still rings the bell when captured (which was my
original issue).

With regard to browser versions, our company standards specify a set of
well-known browsers, whos APIs are well documented. Other than as a
purely theoretical notion, I don't believe that you could point to a
real-world situation where (for a desktop environment) a well known and
supported browser was tossed aside in favor of a different browser than
had X capability, but happened to not support some pre-existing,
well-documented capability.

Finally, as to a browser not being the correct interface model for this
application, I might actually agree there, to some extent. However,
the application in question is a small part of a very large system
which was designed specifically to operate via a web interface. For
this company's business model, the ubiquity of the browser so far
outweighs the minor interface deficiencies, that there would never be a
serious discussion about tossing it aside for a dedicated-purpose
application that had to be installed, maintained, and upgraded on the
client desktop (which is not always under our control) rather than the
server (which is).

Anyway, it seems like we have philosophical differences and it probably
makes sense to just leave it at that. Besides that, I'm guessing that
you have no technological information which relates directly to my
original post? ;-)

Sep 29 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.