Editing layout’s modifiers table is another major function of the Low level editor. The entire lower half of the Low level window is dedicated to this task.
Modifier keys do not produce any characters themselves, but their combined state (on/off) defines which, if any, character is generated by each of the character-producing keys.
KbdEdit supports six modifiers: standard SHIFT, CTRL and ALT, as well as less known KANA, ROYA and LOYA.
Active vs. Unused modifier combinations
The combined state of all modifier keys defines a modifier combination. As each modifier can have two states (on/off), the total number of all possible combinations is 2 ^ <number of modifiers>. For the most common case of 3 enabled modifiers (SHIFT, CTRL, ALT), there are 8 theoretically possible combinations.
Depending on the particular layout, not all possible combinations are actually needed or even valid. For instance, the standard US English keyboard uses only 4 combinations (BASE, SHIFT, CTRL and SHIFT+CTRL). ALT combinations are not used at all, and most keys do not even have a CTRL or CTRL+SHIFT mapping.
Layouts that do use ALT use it only in conjunction with CTRL - typically only ALT+CTRL is used, and sometimes also SHIFT+ALT+CTRL.
To make the layout definitions more compact, the high-level mappings are defined only for combinations that are actually needed, while the unused combinations are completely hidden from view. This is done by separating all modifier combinations into active and unused:
The Active modifier combinations list shows modifier combinations that are used by the given layout. The combinations shown here are available for mapping in the High level editor. The remaining combinations are listed in the Unused modifier combinations.
Combinations can be moved from one list to the other using the buttons ‘←’ (left arrow) and ‘→’ (right arrow).
When a combination is removed from the “active” list, all of its “high-level” mappings are lost too. In this case KbdEdit will prompt you to confirm this potentially destructive operation.
The order of modifier combinations can be changed using buttons ‘↑’ (up arrow) and ‘↓’ (down arrow). The impact of the reordering on the High level view is purely cosmetic - it only changes the order in which modifier combinations are displayed in the "Mappings for the current key" widget, but the Unicode mappings for each affected modifier position remain the same.
This should be contrasted with the High-level editor's feature that allows the drag-drop moving of all keys' Unicode mappings between modfiier positions as a single operation.
BASE combination (no modifier pressed) is somewhat special: it is always active, and must be the first element in the list of active combinations.
KbdEdit allows a layout to have up to 15 active modifier combinations. This limit is imposed by the Windows keyboard layer, which treats position 16 as an internal delimiter value.
If it weren't for this limit, the theoretical maximum with all 6 modifier keys enabled would be max 48 valid combinations. You may notice that this is less than the absolute maximum of 2 ^ 6 = 64. As described above, the combinations including ALT alone, ie without CTRL, are not considered valid. There are 64 - 48 = 16 such combinations, which explains the shortfall.
In practice, 15 modifier positions proves to be more than enough for most practical purposes. In cases where even more mappable positions are needed, alternative methods like dead key chaining may be more practical from the usability standpoint.
Modifier virtual codes
For standard SHIFT, CTRL and ALT modifiers, separate virtual codes exist for “left” and “right” versions: left SHIFT is represented by VK_LSHIFT, right SHIFT by VK_RSHIFT, and the same goes for VK_LCTRL/VK_RCTRL and VK_LMENU/VK_RMENU. The distinction between “left” and “right” variants is immaterial to the end user; it exists only to make it easier for Windows to handle keyboard input.
The ALT modifier’s virtual code is named VK_xMENU instead of something like VK_ALT. The reason is historical: initially, the primary function of the ALT key was to provide a keyboard interface for menu navigation.
Regardless of the modifier key, KbdEdit does not check if the necessary modifier virtual key codes are actually mapped to physical keys – it is up to the user to verify that these mappings are correct. For example, if CTRL is enabled, but no physical keys are mapped to VK_xCTRL, this modifier will effectively be turned off, which may or may not be the intent.
The use of CTRL as a general-purpose modifier is generally not recommended for a couple of reasons:
KbdEdit only allows the editing of CTRL positions because most Windows built-in layouts map at least some ASCII control characters to CTRL and/or CTRL+SHIFT positions. E.g. in the standard US English:
If CTRL positions are to be modified at all, this should be only done to produce control characters in a manner that is consistent with built-in layouts.
The only other permissible use of CTRL is in conjunction with ALT as part of AltGr.
The KANA modifier is special in that it behaves differently depending on which virtual key it is mapped to:
The virtual code is chosen through the KANA mapped to combo box, which is shown and editable if KANA is enabled:
(not that the KANA "mapped to" field is the only one that is editable)
ROYA and LOYA modifiers are bound to fixed virtual codes VK_OEM_FJ_ROYA and VK_OEM_FJ_LOYA.
Even though the "R" and "L" in modifier names signifies "Right" and "Left", ROYA and LOYA are two distinct modifiers - they are not merely "left" and "right" versions of a hypothetical "OYA". This further means that ROYA, LOYA and ROYA+LOYA are three distinct modifier positions - each can be assigned a separate mapping in the High-level editor.
As a small digression, names ROYA and LOYA come from "Right Oyayubi" / "Left Oyayubi". These keys were originally introduced to support specalized Far Eastern (FE) keyboard models manufactured by Fujitsu, but as it turns out they also work perfectly well as general-purpose modifiers on standard keyboard types.
The UWP (Universal Windows Platform) applications have one important limitation: they do not support the "exotic" modifiers KANA, ROYA and LOYA! When resolving Unicode mappings, the state of these three modifiers is ignored, ie only the standard modifiers SHIFT, CTRL and ALT/AltGR are taken into account.
The UWP applications were previously known as "modern" or "Metro" apps. They were first introduced in Windows 8/8.1, and have become more common in Windows 10, with the Edge browser probably being the most popular example.
It is unclear whether the restriction is a conscious design decision, or merely an oversight. In any case, its cause lies deep inside the OS, and is not fixable by KbdEdit. Note that even certain standard built-in layouts are affected by it, eg the Canadian Multilingual Standard keyboard (KBDCAN.DLL, 00011009), which uses the non-togglable KANA in KANA and SHIFT+KANA positions.
Each modifier can be turned on/off using a checkbox placed next to its name. If a modifier is turned off, all combinations it is part of are removed from the "Active" and "Unused" lists. All "high-level" mappings for the removed "Active" combinations are also deleted.
You should keep in mind that even if you deactivate the “modifier” function of a modifier key (by turning its check box off), the modifier key’s virtual code will still keep its non-modifier functions. For instance, if you deactivate the ALT modifier, Windows system shortcuts involving the Alt key will still be accessible (task switching using Alt+Tab, application menu access through Alt+<letter> etc).
To completely disable a modifier key, including all keyboard shortcuts it is part of, it is necessary to remove the modifier virtual code from the underlying physical key(s). This is done either by assigning an “empty” code to the physical key (as described in Editing virtual key mappings), or by assigning it a different virtual code which effectively changes the key’s function.
Using the same example, the ALT key is completely disabled by removing the underlying virtual keys VK_LMENU and VK_RMENU from the layout. The physical keys can be either disabled (assigning VK__none_), or their function can be changed by assigning a virtual code other than VK_LMENU / VK_RMENU / VK__none_.
Can modifier keys be enabled independently of each other?
If you spend any time playing with modifiers, you'll notice that modifier keys cannot be enabled/disabled in isolation: if you activate a particular modifier key, it will automatically activate all modifiers keys that precede it. The most extreme case is LOYA, which is at the very end of the modifier list: you cannot enable this key without implicitly enabling all other modifiers (ROYA, KANA, ALT, CTRL and SHIFT).
This restriction is a consequence of the way modifiers are stored internally, but it is of mostly academic relevance. Far more important is that you do have a full control over which modifier combinations are active and which are not. If you want to enable LOYA, but do not need ROYA and KANA, simply do not activate any modifier combinations involving the latter two. From the practical standpoint, this is same as not enabling ROYA/KANA at all.
Three special flags enable additional modifier-related fine tuning: "Uses AltGR", "SHIFTLOCK" and "LRM RLM".
As stated above, the ALT modifier is never used alone - Windows mandates that it's always paired with CTRL. The combination CTRL+ALT is special enough that it can be treated as a "virtual" modifier key called ALTGR.
If Uses AltGr is checked, "ALTGR" is shown instead of “CTRL+ALT” throughout the KbdEdit GUI. This is not a mere cosmetic change: in "Uses AltGr" layouts, right ALT is also treated differently by Windows: pressing it has exactly the same effect as pressing CTRL and (left) ALT together.
A less known special flag SHIFTLOCK can be used to change the interplay of SHIFT and Caps Lock: if SHIFTLOCK is checked, Caps Lock can be turned off only by pressing SHIFT (normally, Caps Lock is turned off by pressing the Caps Lock key again).
The default effect of Caps Lock on SHIFT is somewhat counter-intuitive: the SHIFT state is effectively inverted while Caps Lock is On (see Caps Lock-related special settings). SHIFTLOCK can be used to correct this problem: it makes SHIFT behave in a predictable fashion independently of the Caps Lock state.
LRM-RLM flag is useful for languages like Arab or Hebrew, which are written from right to left. If LRM-RLM is checked, two special shortcuts are activated which enable the keyboard to be used in bidirectional mode:
Back to Low-level editor
Copyright © KbdSoft 2007-2021