Forcing non-exclusive mode for DirectInput?

Started by
1 comment, last by KIFulgore 15 years, 9 months ago
Hey everyone, I've got an issue with a "game maker" program being used for a class whose game engine was created in DirectX 7. The program allows students to write C++ code to control the behaviors of objects and links their code with a DLL that handles creating the windows, input, drawing, etc. OK, so if students write code that hangs the program in Windows XP, the game just crashes. No problem. In Windows Vista, however, a hung game completely freezes the mouse and keyboard. The window reads "not responding". The only key sequence that works is Ctrl+Alt+Del, which will allow you to log out. I would like to be able to disable exclusive mode for the keyboard (or mouse, or both). The game engine library (presumably) creates the DInput 7 device in exclusive mode, which locks the mouse and keyboard on an infinite loop hang. The problem is, I don't have direct access to the DirectInput device created by the game library (it's not exposed in the "game maker" library or headers). Anyway, just wondering if you had any ideas on changing the CooperativeLevel for a DInput device that's created by a library I have no direct access to or documentation about. If there's a way to force a process to use non-exclusive mode only, that would be great.
Advertisement
Mandatory "Don't use DirectInput for keyboard or mouse input".

Assuming you have no choice however, the only option I see is making a proxy dinput8.dll file, and hijacking requests to DirectInputCreate(), returning your own interface, returning a proxy class for IDirectInputDevice, and overriding the SetCooperativeLevel() function. But that's really not going to be pretty to do. Still, if you want more information on doing that, reply here and I'll go into more depth.
Thanks for the article, too many programmers jump right to DInput for keyboard/mouse when there's no need to. This program I'm working with is circa 2002... so Win95/98 support was needed.

I thought about the proxy/wrapper .dll solution (yeah it would be ugly). I don't want to make the fix too complex though since I'm using this software with a group of students this year.

I'll probably contact the devs and ask if they can re-compile a more Vista-safe version of the library. They're busy working on a new version of the editor, but maybe I can convince them to revisit the old one with cookies...

This topic is closed to new replies.

Advertisement