FrontAccounting forum — Hot keys system for FrontAccounting

Re: Hot keys system for FrontAccounting

null@example.com (apmuthu) — Fri, 15 Feb 2013 17:41:47 +0000

Wow! That's a nice way of managing translation of labels and moving into form fields at the same time! For this to work, we need to have an "id" for each label and it's correspondig form field to be suffixed with a common number something like:

Only then can a generic js included in each form be able to generically do the trick.

Re: Hot keys system for FrontAccounting

null@example.com (itronics) — Fri, 15 Feb 2013 17:08:45 +0000

There is no hot keys support in forms, only in menu and submenus (hot keys work on links).
Adding hot key functionality to form field would be big improvement, but this is quite complex javascript/php task.
The hotkeys could be stored analogicaly as underscored letters inn form field legend text. Anybody interested in contributing the code ?

Janusz

Re: Hot keys system for FrontAccounting

null@example.com (apmuthu) — Fri, 15 Feb 2013 03:14:23 +0000

Hot Key to move to a specific field in a form - how is that achieved?

Re: Hot keys system for FrontAccounting

null@example.com (itronics) — Thu, 14 Feb 2013 22:41:38 +0000

Currently hot keys functionality works fine e.g. on FireFox, does not work propely under Chrome. Hot keys are defined in text messages (or translation files) by preceding respective menu option text letter by ampersand.

There is no need for any list of hot keys, as they are directly visible (as underscored letter) on menu options.
Janusz

Re: Hot keys system for FrontAccounting

null@example.com (apmuthu) — Wed, 13 Feb 2013 09:07:23 +0000

What is the current status of this issue?
Where are the hot key definitions stored?
Any report to list them?

Hot keys system for FrontAccounting

null@example.com (itronics) — Mon, 29 Sep 2008 18:44:46 +0000

1. Hotkey mechanism
One of problems addressed during the implementation was big count of options in some modules which make unique access letters assignement difficult. We resolved this allowing use of duplicated hot keys in following way:
When user press and hold Alt key pressing letter key moves focus in order between menu options with the letter assigned. Then when Alt key is released, currently focused option link is selected.

2. Hotkey map
Current letter to option assignment has been done intuitively rather than systematically, but I've kept i mind following rules:
. Every menu option has access key. If key is used by more than one option user
can select any of them in circle keeping Alt key pressed and touching access
key some times.
. The letter for options should be as unique as possible, yet intuitive.
. Primary use of first word letters.
. Less used group of options like inquires has common access key.
. Options available in more than one module should have the same access key (eg R for reports)
. Arrow keys can be used in menus to navigate between options (since v.2.2)

3.Hotkeys in forms (since v.2.2)
Most forms in FA have default values in fields set on interaction start. To bust form data entry performance default submit button has CtrlEnter hotkey assigned in most pages. If there is some non-destructive cancel button available on given form, Escape hotkey can be also assigned to it. Both active buttons are easily recognized by additional confirm/cancel icon.

4. Compatibility
This mechanism seems to work at all browsers but FireFox 3.0 for Win. At this one case user have to press Enter key to run selected option because of internal bug in this FF version.
The implemented hot keys mechanism is available only in full interface mode, although for non-javascript enabled browsers native access key mechanism (with related flaws) should be available.

The system as for now is available for testing at 3 basic themes (default, aqua and cool). We want to know your opinion about the used implementation and assigned hot letters before going further. We would like to have access key map accepted by FA community before CVS update, because introduced system will force corrections to all language modules, and nobody want to do it more than once. The needed changes in gettextized strings are very simple, and not time consuming, but necessary. This is the price for having independent keymap for any supported language.

Janusz