windows-xp/Source/XPSP1/NT/multimedia/directx/dinput/dx8/dll/kbd.htm

<HEAD>
<TITLE>Future Directions for DirectInput Keyboard Support</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#000000 VLINK=#808080 ALINK=#000000>
</BODY>

<H2>Future Directions for DirectInput Keyboard Support</H2>

<ADDRESS>
Raymond Chen<br>
Microsoft Corporation<br>
11 November 1997
</ADDRESS>

<h3>Abstract</h3>

<p>
Ideas for future versions of DirectInput keyboard support are presented.

<h3>Exclusive Keyboard Access</h3>

<p>
Currently, keyboards are supported only in passive (non-exclusive) mode.
Adding support for exclusive mode on the system keyboard
(<code>GUID_SysKeyboard</code>)
is extremely easy on Windows NT, and
a bit tricky on Windows 9x.

<p>
On Windows NT, all that would need to be done is to have the
<code>CEm_LL_KbdHook</code> function return 1 without calling
<code>CallNexthookEx</code> in the situation where the keyboard
has been acquired exclusively.  This will prevent Windows
applications (including the current application) from seeing
keyboard activity, while not preventing the secure attention
sequence (Ctrl+Alt+Del) from operating properly.

<p>
For Windows 9x, the change would be similar, but more annoying.
The <code>DIKBD_Filter_Keyboard_Input</code>
function would return carry set rather than clear if the
keyboard is captured.  Steal the basic idea from the
<code>dimouse.asm</code> file, which already does this for
mouse events.  (I.e., handle the <code>DIKBD_Capture</code>
notification, set a flag in the instance structure,
and check the flag in the filter procedure.)

<p>
It's actually not quite that easy, because Windows 9x does not
have a security manager.  The low-level keyboard filter procedure
would also need to track the virtual shift state and detect that
the user has typed Ctrl+Alt+Del.  Under such conditions, the filter
would have to force-unacquire the device, then turn around and
re-inject the Ctrl+Alt+Del sequence (now with the filter disabled)
so the system can see it again.

<p>
Note also that
<code>CKbd_SetCooperativeLevel</code> would need to be changed
to understand which modes support exclusive access and which do not.

<h3>Disabling the Windows Logo Key</h3>

<p>
This is a common request from game developers, because the Windows Logo Key
sits right next to two extremely popular game keys - Ctrl and Alt.
Accidentally pressing the Windows Logo key causes the Start Menu to open,
which in turn causes the application to lose focus and possible even lose
its display surfaces.

<p>
This can be solved as a restricted (and much easier)
form of exclusive keyboard access.  Again, on Windows NT,
we would merely check if the incoming key is
<code>VK_LWIN</code> or <code>VK_RWIN</code>; if so, then return 1
immediately without chaining.
On Windows 9x, the filter procedure would check for a scan code of
E0/5B or E0/5C (or their release counterparts E0/DB and E0/DC);
if so, convert the 5B or 5C (or DB or DC) to a harmless key like 00.

<h3>References</h3>

<p>
<cite>
<a href=http://www.microsoft.com/directx/resources/dx5ddk.htm>
DirectX 5.0 DDK</a>
</cite>, Microsoft Corporation.

<p>
<cite>
<a href=http://www.microsoft.com/directx/resources/dx5sdk.htm>
DirectX 5.0 SDK</a>
</cite>, Microsoft Corporation.