People often wonder how we handle cross-platform concepts, and here's one where we did the wrong thing to start off with (IMHO) but ended up correcting it for RB 2005.
Keyboard layouts are different depending on the platform you're working with, both physically and conceptually.
Mac keyboards have four modifier keys: Shift, Control, Option and Command. Command is used to fire menu commands. You use the Shift key to modify the menu command for slightly different results. For example, Cmd+S does Save while Cmd+Shift+S does Save All. The Option and Control keys are also used to modify menus in various ways. Furthermore, these keys have special meaning when using the mouse as well. For example, pressing Option while dragging an icon should cause a duplication upon drop instead of a move.
Windows keyboards only have 3 modifier keys: Shift, Ctrl and Alt. The PC key (the one with the Windows logo on it) is not used as a modifier key since it has special meaning to the operating system. On Windows, the menu key is the Ctrl key -- and it too is modified by the Shift key like the Mac is. However, you shouldn't design menu shortcuts that use Ctrl+Alt since that doesn't work well with international settings. Ctrl+Alt is the AltGr combination, and is the way that many users enter non-ASCII text.
So how does REALbasic handle these differences? It maps keys based on physical location. Keyboard.CommandKey doesn't map Cmd to Ctrl, it maps Cmd to Alt. Likewise, Option maps to the PC key, Control maps to Ctrl and Shift maps to Shift.
This makes sense for people who are designing their applications based on hand location. For example, someone making a video game cares about where the users fingers are placed moreso than they care about the meaning of the keyboard keys. However, most people are writing applications where the key meaning takes precedence over key location.
So REALbasic 2005 addresses this issue a little better than previous versions. The menu editor now lets you assign keyboard shortcuts via checkboxes for example. In these boxes, the meanings are clearly defined: MenuModifier is the main modifier key (Cmd on Mac, Ctrl on Windows), AlternateMenuModifier is the Shift key on all platforms. And it shows you that MacOptionKey and MacControlKey map to nothing on Windows or Linux, and PCAlt key maps to nothing on the Mac. So there are no questions about what menu modifiers are being used. Note that these improvements are just on the menu editor -- they're not on the MenuItem itself. You still should be setting the KeyboardShortcut property manually.
The Keyboard class has gotten some upgrades as well -- it now has Keyboard.MenuShortcutKey and Keyboard.AlternateMenuShortcutKey (and the Async siblings) which map the same way that menus map. Furthermore, one of the most confusing things about the Keyboard class (IMHO) is the Keyboard.OptionKey. I always figured that would map to the Alt key on Windows, which it didn't do. Well, it's been deprecated now -- you should use Keyboard.AltKey instead, which does map to Alt on Windows and Option on the Mac (since most Mac keyboards say Option and Alt, this makes sense). The Keyboard.CommandKey has been deprecated in favor of Keyboard.OSKey (due to the open Apple on it), and maps to the PC key on Windows. I find this slightly confusing from a "meaning" point of view, but from a naming point of view, it's at least more accurate. The way I see it is that if you want the command key to map to something sensible on all platforms, you'll use MenuShortcutKey before you use OSKey -- but it is still sort of a tangled mess in some respects.
So there's you're interesting little tidbit of information for the day. Hopefully you understand the Keyboard class and how it maps to real life a little better.
Leave a comment