Enter key instead of TAB key

Question

Hi folks,
I'd like to make the ENTER key behave the same way as the TAB key in
the system I'm developing. I thought I would be able to do it by setting
the ENTER as a function key (using Window.SetAsFunctionKey), and
then after detecting an ENTER key press, request focus on the current
fieldwidget's 'NextTabField'. However, this attribute defaults to NIL unless
you override the default TAB sequence. And I don't really fancy setting
the Next and Prev TabField for every onscreen field.
Anyone done this before using a simpler method?
By the way, I don't really want to get into a long thread about whether it is
good practice to bypass Windows (TM) standards or not. We require
fast data entry, and keyboard entry is essential for that.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email: [email protected]
PO Box 764, McLean Towers, Phone: [phone]
Shakespeare Road, Napier, New Zealand. Fax: [phone]
Providing Integrated Software to the Meat Processing Industry for over 10 years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Answer 1

Duncan,
The application we are building will replace legacy application and had similar
requirements to accommodate the current users. We solved this problem by creating a
special frame, appropriately named as the "Terminal Frame". It is distributed as
part of the Scaffolds framework.
The Terminal frame implements ENTER instead of TAB key. As you know the tabbing
order in a terminal frame (top to bottom, left to right) is different than windows
tabbing order (left to right, top to bottom). The Terminal frame solves the tabbing
problem by constructing a "field traverse list" which includes all the fields in a
window including nested views ordered according to their X,Y co-ordinates. It is a
recursive method works on the same lines as described by Sakharov, Nickolay in
earlier mail. The method also sets the NextTabField, PrevTabField references for
each field in the traverse list.
This framework is working very well for us. In a terminal frame world, you still
have some user training issues as some of the fields (OutlineField, DropList,
ArrayField, CheckBoxe etc.) behave differently for ENTER and TAB keys. But these
are minimal compared to a complete change in style.
Hope this is helpful.
Good Luck,
Shirish
Duncan Kinnear wrote:
On 22 Jun 99, at 23:47, Jeanne Hesler wrote:
Do the math on this one. Be sure your users understand the cost and the
lack of payback. I have no problem going against common practice when
there is a good reason, but this reason just doesn't add up. Even if it
did slow them down, which it won't, they would never lose enough time to be
worth the work that it would take to implement.Jeanne,
Thanks for your reply (even though it doesn't help me!).
Don't get me wrong, I'm not advocating we abandon the TAB key
functionality in favour of the ENTER key. I just want to ADD the ENTER
key as a navigational aid for our 'legacy' users (and we have many). If it
is done right, there should be no need to tell the user about it. Their
transition to the new product would be virtually painless.
Since I posted my original question I've realised that the cost of
implementation is actually fairly low. And this is why. I have just
discovered that the default tab order defined by Forte (left to right, top to
bottom) is essentially useless for most of the windows we will be creating.
Therefore, we will need to override it by explicitly setting the
"NextTabField" and "PrevTabField" attributes of our input fields in virtually
every window. As I am writing the framework for our new product, I will
have to implement the facility to do this in the framework itself. And if we
have our tab order defined, then adding the ENTER key functionality is
minimal extra effort (see my original post). In fact, if I implement it in my
"CoreWindow" (the root of my windows framework inheritence tree), then
no-one will ever have to deal with it again.
The TAB key is not even much of a windows data-entry standard. Many
of our customers have defined secondary systems using Microsoft
Access, and it uses the ENTER key (along with the TAB key) to move
from field to field. Will these customers not complain that they cannot
use the ENTER key to move between fields if we don't implement it?
As we do not have the resources to completely rewrite our existing
COBOL system (over 2 million lines of code) in one go. We will be rolling
out the new system module by module. This means that a lot of our users
will be switching between the new windows interface and the text-based
unix telnet sessions. When I switch back and forth between windows
editors and 'vi' on the unix host, I experience first-hand how mixed
navigational facilities can hamper productivity!
Anyway, I was just hoping there might be a little setting somewhere in
Forte to switch this on, but as no-one has pointed it out, it seems unlikely.
Thanks again for your input, lively discussion is always welcome.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email: [email protected]
PO Box 764, McLean Towers, Phone: [phone]
Shakespeare Road, Napier, New Zealand. Fax: [phone]
Providing Integrated Software to the Meat Processing Industry for over 10 years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>--
Shirish Kulkarni <mailto:[email protected]>
Sage IT Partners <http://www.sageitpartners.com>
44 Montgomery St. Suite 3200 San Francisco, CA 94104
[phone] Office [phone] Fax
The Leaders in Internet Enabled Enterprise Computing
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>