Note: The specifics are in regards to Windows platforms, but similar concepts apply to all platforms.

A critical aspect of the design of Build-A-Board and its run-time components is the ability to separate the Key Label (what the user sees), and the Key Action (what happens when the key is selected). The user-friendly Key Action for normal keyboard keys (i.e. A-Z, 1-9, etc.) typically uses the same character in Key Action as in the Key Label. This is intuitive, and in normal circumstances provides the builder and the end-user what they expect - click on a key labeled A, and get an A typed into the application they are typing into.

When working with different input locales in Windows, you have options for a floating tool bar, or using a tool on the system task bar that allows you to select the current input for the active window (i.e. the application that has the input focus). Each application can be assigned its own input locale. When the input locale changes, the same keystroke can generate different characters (based on the current input locale).

To accommodate the user-friendly Key Actions (i.e. the character is used rather than a scan code/virtual key code), a lookup is required. This lookup use the Windows API (specifically VkKeyScan) and takes place in the context of the input locale - but the actual input locale used for this lookup is critically important. There are various issues involved and has to do with the assignment of the default input locale to the process that is running. A physical keyboard is a system device, and remains static. So it always generates the same scan code, and how it is interpreted depends on the input locale for the current application that has the input focus. However, the virtual keyboard displayed by My-T-Soft is at its core, a process in the system, and bound by the way the system handles processes. When you run MYTSOFT.EXE it runs in the context of the current default input locale - which may or may not synchronize with a different locale/input as selected for another running application.

For example, let's say you want a Greek layout, but are testing on your development system that has an English default layout, and you select Greek when testing in Notepad. When you run MYTSOFT.EXE it will run (and look up keystrokes in the context of the English layout).

If you use the Greek alpha α character in both Key Label and Key Action, it will not operate correctly. It turns out the correct scan code gets looked up if the Key Action is a (rather than the Greek alpha α). So if you build a layout with the Greek alpha α and use a as the Key Action, it will type correctly when the App you are typing into is selected as Greek. On the other hand, if you put both the Key Label and Key Action as Greek alpha α, and then change the system to be default Greek, then run MYTSOFT.exe, it will type the Greek alpha α into a newly opened app (i.e. everything is in the Greek locale).

The scan code of 65 (hex 0x41) will generate an a in English and a Greek alpha α in Greek, so the better choice would be to just use this scan code (virtual key code) (e.g. %%s065) as the Key Action, because the lookup (which depends on the default locale for input) can change from system to system.

Because the Windows API is used and can change based on the user and system, the user-friendly Key Action as a character isn't as portable as specifying a key code - and much has to do that the "input" is an actual process running on the system rather than a system device.

You can download the IMG Developer's Kit, or just KEYWATCH.exe at ftp://downloads.my-t-soft.com/downloads/KEYWATCH.exe, and use that with different locales, the physical keyboard, and My-T-Soft to identify results based on different settings. This also can be used to identify the scan code (virtual key code) required.

One critical factor is the system default settings - if this is something other than what the builder system is running on, then testing the resultant layout on the actual target is critical to determine operation in that environment. As mentioned above, the approach of changing the input locale for the application works for key codes, but not lookups based on actual characters because of system process issues and the default input locale.

Notes:

• Depending on product, release version, OS version, and specific technical issue, some tech items are very specific, and some may span to other products/versions
• Downloadable files can also be accessed by anonymous FTP at ftp://downloads.imgpresents.com
• Older files are moved into a separate archive location - see notes/details/new location in *.archived.txt text file

• Return to Technical Support

As seen in ...