Exiting Tab Order

[datalink]

Our Go operators enter data on a Go layout with several fields and the tab order moves the operator on from field to field.  The last field in the layout's tab order is a pull down menu field and has an on modified triggered script that simply commits the record.  The idea is that when that last field is modified the record should commit, dropping the pull down menu and allowing the operator to look at the whole record with no keyboard blocking the view before she moves on to the next record/tasks.

Instead though the tab order seems to take over and just moves the focus back to the first field in the tab order, also a drop down menu.  This causes that pull down to appear again rather than releasing the operator from the tabbing loop.

Is this normal or am I doing something wrong?  Suggestions? 

[LaRetta]

You can attach an object name to your heading logo (or anything else for that matter) and then end your script with Go To Object [ "thatObject" )

[datalink]

That doesn't seem to be working for me.  Even with the script that you suggest, which is triggered on modifying that field the tab order goes back to the first field in the tab order.  With the debugger running when the Go To Object step executes I get an error 3.

I've checked and the object names match on the layout and in the Go To Object script step.

Thoughts?

[Rick Whitelaw]

As far as I can tell there's no tab key on iOS. How are the users tabbing from field to field?

[datalink]

Hey Rick,

On iOS key boards Previous and Next buttons appear in the upper left corner of the keyboard.  These buttons navigate the operator to the next field in the tab order (or previous).

For some reason, even a Commit step in a field exit triggered script out of the last field in the tab order still takes the operator back to the first field in the tab order.  Its disorienting for operators that are working quickly in the field.

Suggestions?

[comment]

AFAIK, if your script is:

Commit Records/Records[]

and it is run by an OnModify trigger attached to a drop-down field, the order of operations will be:

1. user releases the mouse on drop-down selection;
2. the cursor moves to the next field object in tab order;
3. the script runs, commits the record and (as a result) exits the field currently active object.

I don't think there's anything you can do to prevent #2. If you're not seeing #3, then perhaps your script is not running after all?

 

 

 

Edited April 28, 2015 by comment