I have often been in the situation where the user wants a list type layout to "arrow-around like Excel". They mean that when they hit the arrows, the active field moves left, down, right, or up the list.
Here is a small script that you can set for a Script-Trigger event that captures the keystroke and does the right thing.
Allow User Abort [ Off ]
Set Variable [ $key ; Value: Get ( TriggerKeystroke ) ]
Arrow Keys
If [ Code($key) = 29 or Get(ActiveModifierKeys) = 1 and Code($key) = 13 or Get(ActiveModifierKeys) = 1 and Code($key) = 3 //Up Arrow or Shift Return or Shift Enter ]
Go to Record/Request/Page [ Previous ; Exit after last: Off ]
Exit Script [ Text Result: Get(LastError) ]
End If
If [ Code($key) = 31 or Code($key) = 13 or Code($key) = 10 //Down Arrow or Return or Enter ]
Go to Record/Request/Page [ Next ; Exit after last: Off ]
Exit Script [ Text Result: Get(LastError) ]
End If
If [ Code($key) = 28 //Left Arrow ]
Go to Previous Field
Exit Script [ Text Result: Get(LastError) ]
End If
If [ Code($key) = 30 //Right Arrow ]
Go to Next Field
Exit Script [ Text Result: Get(LastError) ]
End If
Function Keys
If [ Code($key) = 63236 //F1 ]
# Perform Task
Exit Script [ Text Result: Get(LastError) ]
End If
If [ Code($key) = 63237 //F2 ]
# Perform Task
Exit Script [ Text Result: Get(LastError) ]
End If
If [ Code($key) = 63238 //F3 ]
# Perform Task
Exit Script [ Text Result: Get(LastError) ]
End If
If [ Code($key) = 63239 //F4 ]
# Perform Task
Exit Script [ Text Result: Get(LastError) ]
End If
I find that overriding arrow keys using OnObectKeystroke can be complex and have unintended consequences. For example, stepping through the characters of a field instead of changing field or record. I suggest that overriding the arrow keys be used with the command or control key via a custom menu. I find it easier and safer. Not quite Excel-like… but close.
Moving fields should be done via tab or shift-tab. Excel also does that.
The reality is, this isn’t Excel. When not in an active field, up/down works fine for moving up and down a list.
Tab and shift-tab are more universal and arrow keys. Excel has a hover on a cell but not editing mode. FileMaker does not. Once you enter a field, you are in an active edit mode.
While I agree with that, advocating for more generally accepted practices has long term benefits.
Getting that to work exactly as requested it very difficult if the users also need to arrow around a field. Not that it can't be done, but in my experience, the guy paying the money doesn't want to pay $5,000 for user to be able to arrow around records. Achieving 80% of that functionality in 20% of the time and cost, usually is what they actually want.
You could use the OnModify trigger to set a variable that affects how the arrow key behaves ( move in a field or change records ), but you are still left with how do you know if a user wants to move down a record or move down a row in the field when no edits have been made?
It comes down to what is the relationship with the client. Are you a programmer? Or are you a consultant? A programmer punches a list of requests. A consultant is a partner to help them improve their business and software UX.
I fall into the category of both programmer and consultant. I do mostly process based solutions. Often replacing existing work flows that people have spent years developing with end user tools, like a spreadsheet.
To get early adopters I find it easy to be accommodating for what seem like nit-picky things.
In this case user are doing 10-key-ish entries on many columns and many records. They want to use the arrows to get to the cell to be changed? Accommodate and move on.
