Very many thanks indeed to everyone who has contributed to this thread,
and to Nick F and others who have contributed examples. I have a meeting
with the client next week and will make sure that the various points
that have been raised are discussed and considered before making any
decisions.
I'm going to be away for a couple of days now, so will follow up on any
further posts when I'm back.
Thanks again.
Nick Roper
Nick Fitzsimons wrote:
On 27 Feb 2007, at 18:49:34, Nick Roper wrote:
Just to clarify things a bit, this is indeed and intra/extranet based
application. In fact the project is to convert an existing Access
database application to a web-based PHP/MySQL application that can be
accessed remotely via a secure login. A few admin users will be able
to enter & update data via forms, whilst others will be able to
select/view information and reports. It would only be the admin users
that would possibly have the facility to use the Enter key - which is
what they do with the current system.
As Chris points out, the use of the Enter key is quite common in
data-centric applications (which this is) and the users are used to
using the Enter key for that purpose.
This is, in fact, one of the few cases when it can be worth doing this.
Have a look at
<http://www.nickfitz.co.uk/tests/javascript/entertest.html>
which should do something similar to what you want.
Some notes:
0. It uses a window.onload handler, so that would need to be integrated
with any existing/later code.
1. It uses DOM Level 0 event handler properties, rather than mucking
about with attachEvent/addEventHandler and so forth.
2. This assumes (in the window.onload handler) that the form has an id
attribute of "testForm"; change that as needed.
3. It also assumes that every text input has an id attribute; note that
these must be unique (within the page).
4. It only sets event handling for text input fields (<input
type="text">); you can remove or modify the check in the function
getInputFieldIds if you want, though I haven't tested across browsers
what will happen with other kinds of input field.
5. It tries to avoid creating closures over DOM elements, in order to
prevent memory leaks, particularly in IE. (As to whether or not it
succeeds...)
6. It makes no assumptions about the number of elements in the form, nor
about the form of the element ids, other than that they exist and are
unique within the page.
7. It doesn't set any handler on the last field; this means that, when
"Enter" is pressed in that field, the form is submitted.
The last can be changed to switch focus to a submit button if the test
in getInputFields is modified and the button comes after the other
fields, as is usually the case.
The script would be better off in a separate file rather than being in
the page, but it's just a quick demo :-)
Tested in Firefox 1.5.0.10/Mac, Safari 2.0.4/Mac and IE6/Win.
HTH,
Nick.
--Nick Fitzsimons
http://www.nickfitz.co.uk/
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
--
Nick Roper
partner
logical elements
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
