|
|
The cooperative level of a device determines how the input is shared with other applications and with the Windows system. You set it by using the IDirectInputDevice8::SetCooperativeLevel method.
/* hwnd is the top-level window handle. */
lpdiDevice->SetCooperativeLevel(hwnd,
DISCL_NONEXCLUSIVE | DISCL_FOREGROUND)
The parameters are the handle to the top-level window associated with the device (generally the application window) and one or more flags.
| Flags | Notes |
|---|---|
| DISCL_NONEXCLUSIVE DISCL_BACKGROUND |
The default setting |
| DISCL_NONEXCLUSIVE DISCL_FOREGROUND |
|
| DISCL_EXCLUSIVE DISCL_FOREGROUND |
|
| DISCL_EXCLUSIVE DISCL_BACKGROUND |
Not valid for keyboard or mouse |
For the keyboard, you can also include DISCL_NOWINKEY in combination with DISCL_NONEXCLUSIVE. This flag disables the Windows logo key so that users cannot inadvertently break out of the application. In exclusive mode, the Windows logo key is always disabled.
Note Even if the cooperative level for the application is disabling the Windows logo key passively through an exclusive cooperative level or actively through use of the DISCL_NOWINKEY flag, that key will be active while the default action mapping UI is displayed.
The cooperative level has two main components: whether the device is being used in the foreground or the background, and whether it is being used exclusively or nonexclusively.
Consider the example of a music player that accepts input from a hand-held remote-control device, even when the application is running in the background. Now suppose you run a similar application that plays movies in response to signals from the same remote control. What happens when the user presses Play? Both programs start playing, which is probably not what the user wants. To prevent this from happening, each application should have the DISCL_EXCLUSIVE flag set so that only one of them can be running at a time.
To use force-feedback effects, an application must have exclusive access to the device.
Windows itself requires exclusive access to the system mouse. The reason is that system mouse events, such as a click on an inactive window, could force an application to unacquire the device, with potentially harmful results such as a loss of data from the input buffer. So when an application has exclusive access to the system mouse, created by passing GUID_SysMouse to IDirectInput8::CreateDevice, Windows is not allowed any access and no mouse messages are generated. A further side effect is that the cursor disappears.