I’ve started working on a few classes I’m calling NativeBehaviors, because they rely on intercepting the native Window Message processing, and I’ve put together a simple framework to let me write them, which I thought I would share. The first one I wrote is a SnapToBehavior, which implements a feature that people seem to be constantly re-implementing in apps. Basically, it makes a window snap to the screen edge when it gets close (and prevents them from being moved off-screen). I’ve also written a Global HotkeysBehavior which lets you register Hotkeys that work whenever your app is running (even if another app is active) so you can create a Hotkey to hide your app and show it, or whatever.

In the rest of this article I’ll show you how to achieve this in WPF using my base NativeBehavior class, and how to use it on a Window. Since some of you won’t really care how it works, let’s start with:

How to make your WPF Windows snap to screen edges in 3 easy steps:

Step 1. Add a reference to the Huddled.Wpf.Interop library.
Step 2. Add my Xml namespace to your root Window element
Step 3. Paste three lines from below….

I should point out the “SnapDistance” property of the SnapToBehavior is actually a WPF “Thickness” which lets you specify the distance from the screen edge as a single number to use on all sides, or as a separate number for each side: Left, Top, Right, Bottom. And that’s pretty much all there is to know.

How to implement a NativeBehavior.

The implementation of the SnapToBehavior is actually ridiculously simple, given the NativeBehavior framework. I simply created a SnapToBehavior class which derives from NativeBehavior, and implemented the single mandatory method:

When my new behavior is added to the Behaviors collection, my handler will be registered, and whenever the WM_WINDOWPOSCHANGING message arrives, it will be called. Now I defined a DependencyProperty for the SnapDistance, so that you could set that in XAML. It’s extremely simple, and VisualStudio has a built-in snippet for dependency properties, but here’s the code:

Once I have that, the last piece of the puzzle is to actually handle the window position changing message (think of it as an event, if you’re not used to Win32 message-based programming).

The basics of handling WM_WINDOWPOSCHANGING is that you get a structure passed in which has the proposed position of the Window, (including it’s z-index related to other apps) and you can basically tweak that however you like. Obviously there are lots of possibilities for this single message: always-on-bottom windows, undraggable windows, etc., but in our case we’re just concerned about how close we are to the edge.

We use the SystemParameters class to get the VirtualScreenLeft, VirtualScreenTop, and VirtualScreenWidth and VirtualScreenHeight which define the rectangle we’ll use for snapping. In the case of non-rectangular arrangements of multiple monitors this isn’t quite sufficient, but for our example anything more would be a distraction. Then we just check to see if the proposed position is within the “SnapDistance” of any of the edges, and if so, we change the position to be against the edge. That’s really all there is to it.

If you look at the code example below you’ll see I have to “Marshal” the WindowPosition structure in and out of an IntPtr which is passed in the WindowMessage … that’s the downside of intercepting window messages that the framework doesn’t already translate for us, but in this particular case, it’s actually fairly trivial.

Download it, or get the source code

If you’d like, you can download the current Huddled Interop for WPF library right now, or you can check out the source from CodePlex SVN or just download the most recent commit (You are only interested in the “Huddled” project which is in the “trunk”, not the “trunk-3.5”). The source is licensed freely under the BSD or GPL v2 (and a few other licenses, see the top of the source code files).

Either way you’ll get not just the SnapToBehavior but also the global HotkeysBehavior, and the Native Behaviors framework which I’ll write more about later, but for now, in case you want to try to use it, here’s an example using both the SnapTo and HotkeysBehavior (you can find this in the GlobalHotkeys demo project, which includes some sample code for handling hotkey conflicts). Enjoy.

However, nobody seems to have fixed the F-Lock problem … so I started digging into the command mapping to see what I could figure out. I’ve got a fix posted at the bottom, so if you don’t care how this works, just skip to the end. I’m working on a Natural Ergonomic 4000, but some of what I found should apply to any keyboard using Microsoft’s IntelliType software. What we all know by now is that it has xml-based command remapping. The definitions for the remapping are in a file called commands.xml in the install directory, which is, by default: “C:\Program Files\Microsoft IntelliType Pro”.

There’s two interesting things happening in the IntelliType software. First, the “My Favorites” buttons on the Natural 4000 don’t seem to be a part of this remapping scheme. Second, although all of the remapping can be done in the commands.xml file, the control panel (at least in Vista) doesn’t use the commands.xml file at all — it adds entries to the registry!

The Registry Keys

The mappings from the control panel happen in this key: HKEY_CURRENT_USER\Software\Microsoft\IntelliType Pro\EventMapping and I’ll list the subkeys off here really quick:

• 14 is the back button
• 15 is the forward button
• 18 is the search button
• 20 is the Web/Home button
• 21 is the Mail button
• 25 is the Play/Pause button
• 31 is the Calculator button
• 42 is the F1 key
• 54 is the F2 key
• 55 is the F3 key
• 45 is the F4 key
• 46 is the F5 key
• 47 is the F6 key
• 48 is the F7 key
• 49 is the F8 key
• 50 is the F9 key
• 51 is the F10 key
• 52 is the F11 key
• 53 is the F12 key
• 78 is the First Favorite Apps button
• 79 is the Second Favorite Apps button
• 80 is the Third Favorite Apps button
• 81 is the Fourth Favorite Apps button
• 82 is the Fifth Favorite Apps button

• 73, 74, 75, and 83 are the Left Win, Apps, CapsLock, and Volume keys which can’t be remapped via Intellitype, but can only be disabled.

I’ll add some more information here later about the possible contents of these keys, but the most important thing is this: the Command value dictates what the button does There is also a “ShellExecute” value which has a file path or URL that can be launched if the Command is set to 800 (decimal). The possible values for Command are basically all the different built-in commands — which are listed in the mscmdkey.xml file.

The Commands

The weird thing is that some of the commands in mscmdkey don’t make sense as commands (like RSSI_NOISE_COMMAND or BATTERY_CRITICAL_COMMAND). Additionally, some of them can’t actually be used (you can’t remap F1 to “313” which is the left window key). I’ll mostly let you read the commands for yourself from that file. A couple of them are worth giving more detail about:

• 0 is the “invalid” command which disables the key
• 2 is the special “unassigned” command (the 5 favorites buttons start as this by default, but you can set any of the other settable buttons to this, which would result in getting a prompt when you use it — I do this for the web/home, search, mail, and calculator buttons for other people’s accounts, so they can set them themselves also).
• 800 is the “Shell Execute” command (which causes the value in ShellExecute to run).

• 316 and 306 are the “Lock Workstation” and “Log Off” commands which are quite amusing to set on all of the keys as an April Fool’s joke.

Commands.xml Structure

The real power of the IntelliType system is the Commands.xml file. Unlike the registry settings, which are restricted to remapping the keys from one “command” to another, the Commands.xml file can actually create simple macros. Commands.xml consists of a root node DPGCmd which contains the copyright and version nodes, and a series of language nodes. The most important language node is the global “ALL” language. The “ALL” language contains mappings which are applied on top of whichever language you have your keys set to, and you should be aware of it whenever you’re doing remapping because if you map the same character twice in the same section (eg: for the same app) it will crash the IntelliType driver, even if the mappings are in your language section (eg: ENG for english) and the ALL section. If you only ever use a single language on your keyboard, the simplest thing to do is to just get rid of all the other nodes in the file to avoid these conflicts.

Each Language (including ALL) has a series of APPLICATION tags with per-application key maps. This is actually a very cool feature, except for the fact that they remapped keys like F5 and F3 which already have functions in most apps! At any rate, the key maps are defined as tag like: where the tag name is a C followed by the command number from mscmdkey.xml as mentioned earlier, which identifies the key. There are several possible attributes, but which ones are relevant depends on the Type attribute, which defines the type of remapping — depending on the type, there are additional parameters:

• Type 0 – The simplest remapping, just disables the key.
• Type 6 – Simple on the surface, this just takes an Activator command like “ZoomOut” or “ZoomIn” and “ScrollUp” or “ScrollDown”. The commands seem to be the ones defined in mscmdkey, but in PascalCase, instead of having underscores, and without the trailing “_COMMAND” text …
• Type 5 – is obviously the most useful, because it lets you specify a key sequence like: which specifies keys to press. It appears that you can use the pipe character “|” to separate chords, so for instance “alt f | s” to press alt+f and then press s (eg: open the file menu and hit save). Certain key sequences cause problems, and there seems to be a limit to how many sequences you’re allowed (only 3?) I don’t know the full syntax here.
• Types 1-4 seem to be for sending window messages, but it’s not clear how they work exactly, since 1 and 3 both take only a wParam, 2 takes only a lParam, and 4 takes both.

• Type 7 – I really don’t know about. It takes a “subtype” which is one of the types listed above, and then, whatever additional parameter that type would take … but I’ve only seen it used for the 1003 command, which as far as I can tell is probably the Office Task Pane command, and is only used in MS Office apps (not to mention that a physical button for this doesn’t exist on any keyboards I’ve used).

The Most Interesting Keys

Each of the function keys map to a special command when the F-Lock mode is on … (you know them, because they’re labeled appropriately). For instance, the “Help” command, which is the F1 key, is command 302, so it appears in the commands.xml as <C302 ... />. The other interesting key, to me, is the scroll wheel, which turns out to behave somewhat like a key with variable-speed repeat. I’ve listed them below with the key they map to when F-Lock is engaged:

• 319 Zoom In (we’ll remap this to Scroll Up, for lack of something more interesting)
• 320 Zoom Out (we’ll remap this to Scroll Down)
• 302 F1
• 203 F2
• 204 F3
• 307 F4
• 308 F5
• 309 F6
• 900 F7
• 901 F8
• 902 F9
• 401 F10
• 311 F11

• 310 F12

The download

Having said all of that … the simplest thing to do is to just delete the whole EventMapping key and remap the F1-F12 keys in the commands.xml using an XSL style sheet like the one Olivier suggested. So, heter’s my IntelliType Fix – Right-Click and “Save As” to download it, and then apply it to your Commands.xml file. If you don’t know how to use an Xsl file, you could use my Xslt PowerShell script and make a backup copy of your commands.xml called commands.xml.old and run this, in PowerShell: