Accelerator Keys

The concept of Action Defaults allows you to code your 4gl independently of how actions are triggered.  If you have ON ACTION zoom, your code does not care how the zoom action was triggered.  The runtime does not care whether the user pressed a function-key, whether they clicked on a BUTTONEDIT icon, whether they clicked on a TOOLBAR item etc.   Whereas if you have coded COMMAND KEY(F5), or ON KEY (F5), then you are restricting the triggering of that action to the user pressing F5, the question you then ask yourself is, “where is the F5 key on your tablet or phone device”?

With ON ACTION action-name, you can still indicate a key that can be used to trigger an action.  This is achieved via the acceleratorName attribute in the .4ad file, or via the ACTION DEFAULT section in you form, or via the ATTRIBUTE(ACCELERATOR=) syntax in the 4gl.  Ideally you are doing this in the .4ad file so that you only define this once in your code base.

My desired coding standard is…

• zero use of COMMAND KEY(key), ON KEY (key), COMMAND command-name
• use ON ACTION action-name throughout your 4gl.
• Define actions used throughout your application in a single .4ad
• if an action is used only once then it is permissible to use the ON ACTION action-name ATTRIBUTE(ACCELERATOR="key") … syntax rather than clogging up a .4ad

This typically means that actions such as zoom, query, add, update, delete get defined in my .4ad with an image and accelerator that is used throughout my application.  One-off actions that typically don’t have an image or accelerator key are defined once in .4gl where they are used.  These actions are typically rendered as a series of buttons or in the action panel. If I did choose an accelerator for these one-off actions, this accelerator would not be unique to this action and might be reused for other one off actions.

We ship a default Action Defaults file $FGLDIR/lib/default.4ad.  This should form the base of your own .4ad with your additional actions appended to it.  Remember to Patch and not Copy so you get any new actions we add.  Occasionally we see the accelerator keys changed in your .4ad and this is what I want to comment on…

• A common request is to change the behaviour of the Enter key on the numeric keypad so it triggers the nextfield and not the accept action.  I believe this is a reasonable thing to do and discuss this in a previous Ask Reuben .
• The help action has an accelerator of F1 whereas Informix-4gl used Control-W.  In a GUI environment, users are used to pressing F1 for help, I don’t think you want to deviate away from using F1 for help.
• The actions insert, append, update, delete have accelerators of F3, Control-F3, F2, F4 respectively.  I am not sure where those key assignments came from.  Informix-4gl had insert, delete, next, previous mapped to F1,F2,F3,F4.  I normally edit these actions to have a Control key accelerator reasoning that users are used to. Control-N for New, Control-O to Open, Control-D to Delete inspired from products such as Windows Explorer or Microsoft Word and Excel.
• Finally, and this triggered the article.  Use of a .4ad does allow you to change the keys used for accept and cancel actions.  FGLDIR/lib/default.4ad sets the accelerator keys for accept and cancel to Return and Escape respectively.  In a GUI environment, this is what users are used to.  Yes, you can change these to accept=Escape, cancel=Control-C (the Informix defaults) or accept=F12, cancel=Delete or some other combination to map what the user is used to in their TUI environment, but I believe you should stick to the default GUI keys.  Once users are in a desktop, web, or mobile environment their mind moves very quickly to  accelerators that are associated with that environment.    For example once prompted with a GUI login/password dialog, a user will quickly associate with using TAB to move between login and password, and pressing ENTER to submit the login and password.  When moving from TUI to GUI you should not be afraid to change your accelerators to those appropriate for a GUI environment.  I have seen some .4ad recently still using accelerators from the TUI application (Escape to accept etc) and it is a pity the developers have not taken the opportunity to modernise their application in this area. They will find the end-user resistance is much less than they anticipate.

Final point is this, your 4gl codebase maybe littered with COMMENT, MESSAGE, ERROR referring to accelerator keys for actions.  If you do change an accelerator key, you have to remember to find and edit these COMMENT, MESSAGE , ERROR instructions.  Creating a library function to read the accelerator key from your .4ad or using localization can help in such circumstances.