This feature is implemented through the &xwp; PM hook as well. To understand how this is working (and before you use the "Function keys" page), the following explanations should be understood.

Keyboard processing is a complex issue under any operating system. It involves interpreting hardware messages and translating those according to the current language settings.

Under &os2;, this processing is done on several layers of the system. For one, there is the hardware keyboard device driver which gets loaded though a BASEDEV statement in &cfgsys;. This one reacts to hardware interrupts raised by the physical keyboard hardware and thus receives really every single keystroke on the system.

The &os2; Kernel then processes those keystrokes for the application which currently has the input focus. Further processing is different depending on the type of application. Presentation Manager (PM) applications (including the Workplace Shell) usually receive a message that a key has been pressed or released. The &xwp; PM hook can thus intercept these messages and manipulate them. (This is how object hotkeys work as well, by the way.)

Unfortunately, the default &os2; keyboard processing is still based on the original 101/102-key IBM-compatible AT keyboards introduced in the 1980's. Today, many keyboards have additional keys which are not recognized at all by &os2; or simply produce a character output even though they aren't really supposed to.

Those extra function keys could be the three "Windows" keys found on most keyboards sold today. In addition, there are some extended keyboards which have additional "multimedia" keys. Also, many laptops have some extra keys.

The &xwp; PM hook can identify the physical key which has actually been pressed by evaluating the hardware scan code of the key, which is passed to any PM application directly from the keyboard hardware. On every keyboard, every key should have a unique such code. This code has nothing to do with the ASCII code of a character, it's just a unique number assigned to each physical key on the keyboard. For example, the "Shift" key will have such a code as well as the "A" key, even though the "Shift" key alone will produce no ASCII (character) output.

So the &xwp; hook needs to know the hardware scan code of your function keys in order to be able to react to them. As a result, you will need to register your extra keys with &xwp;. Those keys are then called "&xwp; function keys" and will be recognized by &xwp;. You can, for example, use them as object hotkeys after having registered them.

To register such a function key with &xwp;, go to the enhanced "Keyboard" object and switch to the new "Function keys" page. Right-click on the container whitespace and select "Add function key". You'll get additional help by pressing the "Help" buttons there.

Warnings.

1. There is virtually no error checking when registering a function key with &xwp;. Scan codes are hardware-dependent, so there's no way for &xwp; to tell whether a certain scan code really shouldn't be registered. For example, you could also register the "Enter" or any character key as a function key, which really isn't a good idea. So register only "real" extra keys with &xwp;, or the key might no longer work.

2. Some keys will refuse to be registered. If this happens, this means that the keyboard hardware doesn't produce a scan code for the key. I have a Fujitsu multimedia keyboard with some 15 extra keys, and three of them just don't work. I guess we'd need a device driver to interpret those extra three keys, but this is beyond my knowledge.

3. As usual, the function keys will only be detected while a PM window has the focus. They will not work in full-screen DOS or full-screen &winos2; sessions.