FOR IMMEDIATE RELEASE
Editorial Contacts: Tracy Chang
For further information, please contact
Innovation Management Group, Inc.
IMG@imgpresents.com
XP Embedded - a componentized operating system
An interesting support item shows off the componentized aspect of XP Embedded and low level support of keystrokes within Macrobat (The Macro Batch Processor component of IMG's Build-A-Board). A large corporate customer rolling out a POS type system reported a software problem from within Windows caused by using the @ symbol via the Key Action. Here is the background:
In order to make the Key Action property within Build-A-Board as intuitive and user-friendly as possible, simply specifying the desired symbol is supported. For punctuation, such as the @ or % or # symbols, you can simply match the Key Label and Key Action, and everything works fine. However, when you get down to the actual emulation of the keystroke, you will find there is no single keystroke / keyboard scancode that can generate these symbols - a whole lot of action takes place within the keyboard driver to process and parse keyboard events so that the user-interface matches the physical keyboard, and indeed, you must be in the Shift state to generate certain characters, e.g. it really is Shift-2 at the keystroke level to generate the @ symbol. (Interested parties can read-up on TranslateMessage and the WM_CHAR message for the way some of this is handled within Windows). Flipping it around the other way, there are API calls such as VkKeyScan and MapVirtualKey that can query the underlying keyboard driver to take a character and figure out what keystrokes are required. And things work great - up until you build a version of the OS that doesn't have (or fully support) certain API calls - which is something you can do within a componentized operating system such as XP Embedded.
One solution (and probably the best) would be to rebuild the OS with the required components. As you get close to roll-out time, however, doing something that far back in the chain is generally looked at as a really bad choice. There is also the cause and effect aspect. The problem occurs when the user types the @ symbol keystroke on My-T-Soft, ergo the problem is with My-T-Soft - (regardless that My-T-Soft works fine everywhere else but on this specific version of XP Embedded).
So how to fix the problem? Sometimes it helps to redefine the problem, or run through the issue backwards, so here goes... Macrobat is the Key Action processing part of My-T-Soft, and it generates the virtual key events (and can also perform other actions). So when you pass it an @ symbol, it needs to figure out the keystrokes necessary to generate this via scancodes, and the Windows API MapVirtualKey can do so. The Shift state of these punctuation symbols was the common thread, so some combination of the XP Embedded OS, Macrobat, and the handling with the Windows API calls for these shifted punctuation characters was the problem. (In digging deeper, a whole separate sequence of code within Macrobat gets called to handle older DOS apps when a shifted character is revealed by MapVirtualKey, and various other Windows APIs are called to facilitate this management - our guess it isn't the keyboard APIs, but some of this support code - but without this code, other customers running this version would experience shift issues in DOS apps (which is still an issue for legacy systems - even this year (2011) we've had 1 customer want Windows 3.1 support for a DOS app (sometimes the real world is quite different than marketing hype might lead you to believe!))).
So could the whole situation simply be avoided? Yes - simply specify the Key Action to be the more detailed, totally un-user-friendly actual keystrokes - e.g. instead of using just the "@" symbol, specify "[Shift-Down]2[Shift-Up]". Now Macrobat will never branch into the problem area, and will operate as intended!
But is there any downside? In this situation, not really. The reason the @ symbol by itself is preferred is two-fold - easier for the human, and more portable. In this case, portability is not an issue - this is the OS, and as long as the user gets an @ symbol typed with they press the @ key, all is well. Since the keyboard layout is custom, and specific to this project (and could always be changed via Build-A-Board), changing a handful of keystrokes to be expanded and more specific is acceptable. It resolves the issue, and prevents potentially serious timetable issues if a more drastic fix were to be required. The flexibility of breaking apart the user interface and the Key Action is a crucial engineering aspect of the My-T-Soft® Build-A-Board System, and this is an example of the underlying design of the software. The use of a flexibile componentized OS resulted in a problem, but the flexibility of Build-A-Board quickly resolved the issue.
Return to IMG's Blog Display...
