| Microsoft DirectX 8.1 (Visual Basic) |
The cooperative level of a device determines how the input is shared with other applications and with the Microsoft® Windows® system. You set it by using the DirectInputDevice8.SetCooperativeLevel method, as in the following code example:
'hwnd is the top-level window handle.
Call diDevice.SetCooperativeLevel(hWnd,
DISCL_NONEXCLUSIVE Or 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.
Note The hWnd property of a form does not become valid until the form is shown. If you are initializing the Microsoft® DirectInput® device in the Load method of the application's main form, you must call Show before attempting to set the cooperative level.
Although DirectInput provides a default setting, you should still explicitly set the cooperative level because this is the only way to give DirectInput the window handle. Without this handle, DirectInput cannot react to situations that involve window messages, such as joystick recalibration.
The valid flag combinations are shown in the following table.
| 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.
A foreground cooperative level means that the input device is available only when the application is in the foreground or, in other words, has the input focus. If the application moves to the background, the device is automatically unacquired, or made unavailable.
A background cooperative level really means foreground and background. A device with a background cooperative level can be acquired and used by an application at any time.
You will usually want to have foreground access only, since most applications are not designed to respond to input that takes place when another program is in the foreground.
While developing an application, it is useful to employ conditional compilation so that the background cooperative level is always set for debugging. This prevents your application from losing access to the device every time it moves to the background as you switch to the debugging environment.
In most cases, the fact that your application is using a device at the exclusive level does not mean that other applications cannot get data from the device. Also, an application that requests background exclusive mode may lose access if another application requests exclusive access. The application can regain access to the device by manually unacquiring the device and reaquiring it.
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 DirectInput8.CreateDevice, Windows is not allowed any access and no mouse messages are generated. A further side effect is that the cursor disappears.