BR Forum

Hi all,

Many of my users have been with me from before the beginning of time (the 1980s) when we couldn't do RINPUT FIELDS with arrays in "full-screen" mode in BR, then (Workstation Basic). This was when each field had its own input statement and you used Fkeys to go backwards one field, etc. Anyway...when RINPUT FIELDS MAT...came along, I still allowed them - for the sake of continuity - to use ENTER to advance to the next field. In the RINPUT FIELDS input loop, I simply incremented CURFLD so when I went back to the beginning of the loop, it was on the next field. Still with me?

Well, now that we are completely rewriting their application from the ground up, I'm toying with the idea of weaning them from the "Enter key habit" and trying to go with a more standard TAB key navigation. I suspect that it will not be received well, since they have another BR system that they use (not written by me) which still uses the ENTER key. So much for continuity.

For those of you who do full screen processing with RINPUT FIELDS MAT... and ESPECIALLY for those using GUI, do your users use TAB to advance to the next field? Or do they still use the ENTER key?

-- Susan

Susan,
In a 3.83 WB version I used rinput fields mat - the enter key was used to signify that they were finished with the screen, which then went into data validation. We used the up arrow, down arrow, tab keys to move to the next field.
In full screen processing, I think that the enter key behavior is supposed to be like this.

In Full Gui on mode with 4.1x and above you have some options.
To make the enter key advance to the next field.
For Grid/List
At the bottom of the routine for data entry-
If FK=TAB OR FK=0 Then Let CURFLD(1,AC+1) ! tab, or enter advances cursor 1 field - in a Grid/List !: goto input

In a rinput field mat stmt:

Inp_scrn: rinput mat fields:
after input,
Let CURFLD(CURFLD+1) ! advance cursor 1 field - use with et attribute

and at the bottom of your data validation for this screen, before going to the next rinput screen

If NOT AK OR AK=DN OR AK=TAB OR AK=LEFT OR AK=RIGHT OR AK=UP OR AK=FLDPLUS Then Goto INP_scrn ! @@@ prevent flash (tab,enter,arrows,plus) - additional coding is required for left, up to get cursor on the desired field.
not ak or ak=0 - here means "enter"

any of these keys will advance cursor 1 field, and take you to the next input field
You have to either click on another button - "Exit","Done","Cancel" or another tab,
or use PGUP, PGDN to get out of this screen

Hope this helps.
Doug

Thanks Doug. This is very helpful. I was trying to find out of other people still allow the ENTER key to be used to advance to the next field. It sounds like, although it's possible, you do NOT do this. That's what I was interested in.

Right now, I do something similar to you, although I have some validations that must be run as the user goes through the screen (especially things that go get information from other files):
beginloop: INPUT LOOP (RINPUT FIELDS MAT...)
if curfld=10 then
go get some data from another file and display
end if
if curfld=14 then
do something...
end if
CURFLD(CURFLD+=1)
goto beginloop

Then when they exit the screen (usually via a button), I do some other validations and check to make sure that they aren't exiting a screen (without saving it) if they have made changes. If they have, I display a msgbox and give them the option of saving.

-- Susan

With BR 4.1x and Macs, yes we do still allow the enter key to advance the cursor 1 field.

ak=fkey

if ak=0 (means enter)

Oh, I get it now (a little slow today <s>). Thanks.

-- Susan

I still use the enter key to move to the next field.

I use enter, and most of my clients (yes,I still have some installations out there) use enter and would be as angry as I am when I run into that occasional piece of software from others that accepts the entore screen on pressing enter. Fortunately most of the software that I run into that uses the Enter key to accept the screenas opposed to moving to the next field, has a configuration setting where you can change the behavior to allow Enter to just move to the next field.

If you are going to force users to use the TAB key to move to the next field then I suggest you have a configuation setting to allow them to un-do your change. To my way of thinking enter data in field, press ENTER for the next field is the logical behavior. TAB can be used also, and if you have an "X" attribute the program behaves the same way (unless of course you have put a "T" attribute somewhere).

FNGeorge

Interesting responses. I guess I assumed that most people were using TAB and only *I* was still using ENTER. I suspect that if I eliminated the "ENTER" option, the client would call me right back and tell me that I have to change it. So perhaps this is not the time to get all "modern" on them

It's unanimous. I should keep ENTER as an option. I just needed some feedback and you all are my "water cooler" colleagues. Man, I love this forum (and this group)! Thanks for the input everybody.

-- Susan

Page 33 of the Advanced Capabilities manual (published in 1997) describes an interesting use for FKEY in conjunction with CURFLD. If you specify

Let CURFLD(CURFLD,FKEY)

BR automatically positions the cursor wherever it would have gone if you did not force an exit with X or AE. The wiki has an abbreviated example of this, but doesn't discuss it much, so it is easy to miss:

00010 INPUT FIELDS "10,10,V 10,U;11,10,V 10,U;12,10,V 10,U",attr "HU":X$,Y$,Z$
00020 IF X$="" THEN LET CURFLD(1,"RX") : GOTO 10
00030 !.. other editing
00040 IF FKEY>100 THEN LET CURFLD(CURFLD,FKEY) : GOTO 10
00050 !.. output

ADS expects that line 40 will become a standard line of code in all programs that use input fields and validate data.

I don't know when the extensive discussion of this that is in the Advanced Capabilities manual was abbreviated. But even the current New Console manual and the wiki state:

Previously, the CurFld system function supported 3 parameters:

1. The relative field number.
2. Optional additional field attributes.
3. An optional FKEY value to be applied for cursor positioning before processing the INPUT.

In the event the first parameter points to a 2D field/control then instead of the FKEY value, the third (or second numeric) parameter is interpreted as the subscript of the item within the 2D control.

Note item 3 in the above list. I removed the direct use of FKEY in conjunction with 2D controls because I wanted to discourage BR programmers from micro-managing keyboard entry and I wasn't sure about the speed of client server connections. The Internet wasn't as fast or reliable as it is now. Let me know if this is a feature that is likely to be used if it were added to 2D control support.

Note that the number of responses is significant in this discussion.

I've been using this for years (ever since the announcement) except I use ENTER to move from field to field so my line is:

If NOT FKEY then let curfld(curfld+1) else let curfld(curfld,fkey)

Of course, I generally trap FKEY into a variable first so it's really

LET AK=FKEY : LET AF=CURFLD
If NOT AK then let curfld(AF+1else let curfld(AF,AK)
GOTO XXXXX

FNGeorge

After discussing this with Dan, I realized that I totally forgot about NXFLD, NXTROW and NXTCOL.

With 2D controls NXTFLD points to the control (within the FIELDS array) and NXTROW and NXTCOL identify the cell within the 2d control that would be the next to be processed had control not returned to the program.

This enables you to handle the cursor or focus resetting in a single routine irrespective of whether the field was exited with the mouse or the keyboard.

These are 4.2 features.