Full support for JIS keyboards

[AuralArch]

I feel like this should possibly be listed as a bug; although I decided that missing functionality isn't really a bug. So, anyway...

What I'm most importantly referring to is support for the additional modifier keys found on JIS keyboards. These keys are supported by Windows and the keyboad/input APIs, although documentation seems to be extremely limited/poor; virtually non-existent. A good example of their use; and proof that they are supported by Windows is the keyboard layout design software KbdEdit http://www.kbdedit.com/
Up to 15 unique modifier state 'layers'/'levels' can be created, and the output files are in the default MS keyboard layout format and can be installed in Windows without any extra software.

Ideally the additional modifiers also need prefix symbols for AHK.

Along the same lines: AHK needs improved and complete support for recognizing and fully utilizing CAPSLOCK (separately from shift). Essentially it needs to be treated as a modifier, a unique one; and a locking one. ScrollLock and NumLock states also need improved support as well; for determining and utilizing their states much more completely.

Support for making all of the modifiers locking or sticky, much like how Karabiner does for MacOS https://pqrs.org/osx/karabiner/


Any thoughts/feedback on this?

Thank you so much!

[lexikos]

You are correct; the absence of support for things the program is not intended to support is not a bug.

For the key names, is pull request #55 suitable?

What is "improved support"? What would it allow that is not already possible through the use of more general mechanisms, such as #If?

AutoHotkey's keyboard hook uses tables (two-dimensional arrays) to map modifier+VK/SC combinations to hotkey IDs. Adding modifiers to this table would multiply its size. It is perhaps a small cost, but one that would be paid by thousands of users who have no need for JIS support.

There are limited number of ASCII symbols available for modifiers, though I suppose if the modifiers are only on Japanese keyboards, they needn't necessarily use ASCII symbols.

Any key can be used as a modifier by utilizing a custom combination (key1 & key2) or #If GetKeyState().

Support for making all of the modifiers locking or sticky,

What would the syntax be, and what would it do, precisely?

[evilC]

FWIW, if there is stuff you cannot do in AHK with JIS keyboards, then we may be able to do it with AutoHotInterception (See link in Signature)
It would obviously require installing the Interception driver, but it may allow AHK code to subscribe to key events that AHK normally does not support.
You could then potentially mix this with normal AHK hotkeys wrapped with #if conditions that make them only apply if one of these modifiers is held.

[AuralArch]

@lexikos: Thank you so much for your response! You have provided some very helpful insight and posed some good questions and ideas!

I looked at the list you mentioned; many of those are actually not the ones I'm referring to—or even on my keyboard. I'm referring to the Kana key; which should not be mixed up with OEM_COPY! Kana is a locking modifier key which changes the output from the Latin alphabet to the Japanese syllabaries. Since AHK doesn't treat it as a modifier, or even recognize that it is locking, it is interfering with its function as such (and accessing the characters in those additional keyboard layers).

Essentially AHK sees the keystrokes but it doesn't recognize them. I have been able to use them to some extent using the (key1 & key2) method (which I use abundantly in my AHK script in general), but it is limited since I can't add any other modifiers and the locking aspect is not recognized; and I haven't been able to work around the issues caused so far.

I haven't used the GetKeyState() yet, but it seem potentially helpful; I need to research and test it to find out. Although it does seem to be a very cumbersome procedure for what would otherwise be very simple if these keys' were recognized for their intended function. The fact that these keys are simply "unknown" has been presenting challenges and limitations on how I can use the keys—at least as far as I can tell... However, as you can certainly infer, I'm not too adept with AHK so it's likely there's something I'm missing or overlooking! So I very much appreciate your all of your feedback and questions!


Have you had a look at the link I provided for KbdEdit? I think that would be very helpful in understanding what I'm talking about. I could try to explain it myself here, but the site's online manual and the help documents will explain things much better than I could! Check out this page specifically: http://www.kbdedit.com/manual/low_level_modifiers.html

Although my keyboard does have them I've remapped other IME keys which I don't actually need to the LOYA and ROYA modifier keys which are much more useful and make it possible for me to add multiple "shift levels/layers" to my keyboard layout. These rarely used, and other modifier keys which are actually supported by Windows, although documentation is very hard to find, are explained quite well on the page above.

I think that the list of VKs also found on the KbdEdit site and their descriptions/explanations/usage is a great source of collected information which would be very helpful and useful for anyone who is unfamiliar with the extra/additional/unique keys found on various keyboards and would provide and excellent resource.


My reason for using KbdEdit is to support text entry in multiple complex scripts, plus the IPA (International Phonetic Alphabet) without having to change keyboard layouts which can be troublesome and quirky, as well as bothersome—having everything I need on the different layers (modifier states) of ONE keyboard is by far the best, ideal solution!

I definitely understand your concern about expanding the modifier tables and the increased memory involved; even without knowing the actual amounts, it doesn't seem warranted to apply that to all users without JIS keyboards.... Although, KbdEdit (the premium version which I have) can produce standard layouts (installable dll packages on any system without KbdEdit or any other 3rd party software) which remap keys on an ANSI keyboard to the unique keys on a JIS keyboard (such as the left or right modifiers)... Even without the need for entering multiple writing systems those keys could be interesting to other users and keyboard/hotkey enthusiasts.

In any case, perhaps another version of AHK could be made—exactly like the standard edition except with the additional support for the modifiers and extra keys on JIS and ISO keyboards so that only the users who choose to install that version would have to "pay" for their price in memory consumption. Although I am naive about software coding, I don't know how much work would actually be involved in adding the necessary code to provide functionality for these keys. And it may not be as simple or straight forward as I imagine to maintain there after. In my mind once the necessary code for the additional keys was added, from then on any other updates or changes could also be applied to the JIS version with minimal effort. That seems totally plausible to me, and may actually be possible, but I realize that in real life it may not be that simple...

One thing that I can do with KbdEdit is to produce and post a keyboard layout which remaps standard ANSI keys to the special JIS keys, that would at least anyone to test their function even without having a JIS keyboard. It seems like a reasonable and acceptable solution, even if not exactly perfect... Keys such as the Apps Key, Scroll Lock and Insert seem like excellent candidates to be remapped to Kana, Loya and Roya for testing purposes since those keys are rarely used otherwise by most software. This solution avoids changes to the registry or even addition to the AHK script and as a standard keyboard layout can be activated and switched to/from as such with the taskbar widget built into the OS; meaning that it would be a completely temporary change that could be turned on and off easily and quickly without requiring restarts or even loading/unloading an AHK script.

As far as my definition of "support"... I mean: the keys are recognized by AHK and at least the modifier keys given names, and prefix symbols (which do not need be ASCII characters, however, there are some good candidates for additional prefixes: §, ±, ¬, †, ÷, ¡, ¤, ×, «, » which lie within the ASCII range and do not seem to have any other special meaning or use in AHK or any other conflicts that I'm aware of. Of course, I realize that in order to actually use them (without difficulty) in one's scripts, they would need to be able to type them. And for that some changes would have to be made somewhere; one obvious solution would be to add a few lines to the default AHK script (which could be posted for users to add "as is" or customize first. Those lines could even added the default script that installs for that version with instructional comments on how to type them—using shift+alt combinations has worked well for me and has not revealed any conflicts with native OS (or other app's) hotkeys, shortcuts or functions. Of course, it's easier for me to provide support using KbdEdit as that is its designed function, whereas AHK is more suited to executing actions, commands—programmatic access and control (rather than adding mappings for special characters, although it is of course possible).
Are there any reasons why the prefix symbols for the additional modifiers could not be selected from that list of characters (or potentially others... although those seem best suited to me)?

I wish that I were capable of creating the code needed to add this support myself! But my attempts to learn programming languages seems inherently limited by a form of dyslexia that I suffer from. I have been able to come up with "hacks" and coping mechanisms for most of the effects involving most tasks and activities; but it feels like a brick wall when it comes to coding.

[AuralArch]

@evilC Thank you! I will definitely check out the tools in your signature! That looks and sounds promising! Awesome...

[AuralArch]

@lexikos: BTW, forget to respond to the last question.... Or rather state that I don't have any suggestions for the potential syntax that could be used. But the ability to make any of the modifier keys behave like caps lock (perhaps when both pressed together, or double-tapped to turn on and pressed again to turn off) could be very useful and interesting. There are all kinds of applications and possibilities for use...
I'm not sure of built in support in Windows, but the USB specification for HID includes locking modifiers; and *nix OSes include support natively; and Mac has tools which provide support (using otherwise unused, low-level support in the OS I believe).

[lexikos]

But the ability to make any of the modifier keys behave like caps lock (perhaps when both pressed together, or double-tapped to turn on and pressed again to turn off) could be very useful and interesting.

Do you mean like Sticky Keys, the built-in-to-Windows accessibility feature? I don't personally find it useful or interesting.

Send can put any key into either state ({key down} or {key up}), in response to whatever stimulus the script can detect, such as key-press (key::) or key-release (key up::), and can be dependent on timing (Sleep/SetTimer/A_TickCount) or whatever logic you can think up and translate to code (e.g. number of times pressed within a time period). If Sticky Keys doesn't behave how you want, you can write a script that reflects exactly how you want it to work.

For the JIS features, I am unlikely to take sufficient interest to understand the workings of these keyboard functions that I'll never use, or what it is you want implemented, let alone to actually implement it, even if a reliable alternative to JIS hardware can be devised for testing. I am not likely to even add names for keys that I don't have, except via GitHub pull request from another developer, with confirmation from other users that the patch works and is appropriate.

[AuralArch]

Fair enough regarding the JIS features and key names. Obviously not the response I was hoping for, but it is understandable. And at least you are honest and genuine. Thank you very much for all your help and candor!

I have to say that I am somewhat surprised that you aren't even a little bit curious about what you might be able to do with an another modifier key. Since you don't need to have a JIS keyboard to use the registry method of remapping a key to one of the JIS modifiers (as I've done on my laptop). But perhaps there is nothing that you would do that could be accomplished with an additional modifier that you can't already to with AHK. My main reason is to be able to easily enter an extensive range of characters from several writing systems using a native keyboard layout and without changing layouts—not typically useful to most individuals...

I will do more research into alternate ways of achieving my objectives.

Thank you for your assistance with sticky keys, although I haven't found sticky keys useful either.