direct input
Author
quote:Original post by J_Vitel
Isn´t it even showing the message box you placed inside the case statement??
ha, nope. I don''t get it...
mmmm, so where are you calling your WinProc function? are the other events being called properly??
The way I''ve done it is I have a boolean variable for the key state (such as bSKeyDown).
On the KEYDOWN message, I set bSKeyDown to true and process a keystroke for the S key. But I only process it the first time; if another KEYDOWN comes but the bSKeyDown is already true, I don''t process the keystroke.
On the KEYUP message, I set bSKeyDown to false. Then when another KEYDOWN message comes, I can process the keystroke again.
On the KEYDOWN message, I set bSKeyDown to true and process a keystroke for the S key. But I only process it the first time; if another KEYDOWN comes but the bSKeyDown is already true, I don''t process the keystroke.
On the KEYUP message, I set bSKeyDown to false. Then when another KEYDOWN message comes, I can process the keystroke again.
Author
quote:Original post by J_Vitel
mmmm, so where are you calling your WinProc function? are the other events being called properly??
There is no explicit call to MainWndProc, when the winow is made it is set to use MainWndProc. The other functions I have for menu items etc.. and the WM_DESTROY is being called and thats in there as well.
Is this what you mean?
As others have said, you problem is most likely from the bool value rapidly toggling between true/false every time you press the key due to high frame rates. What you need to do is:
//once only initialisation (do not put this in your loop)bool keydown = false;bool keypressed = false;(loop)keydown = KEYDOWN();if(keydown && !keypressed){ keypressed = true; playsound != playsound;}else if(!keydown){ keypressed = false;} 
The real question is, Are you still using DirectInput? If you are, is your cooperative level exclusive? AFAIK, DirectInput can not share the keyboard with the Windows message queue within the same application - it''s a one or the other situation. Of course, I could be wrong...
The cooperative level dictates whether DirectInput relinquishes control when its window is not the foreground or focus window. That''s to allow it share access with other applications.
If you''re still using DirectInput for other purposes, you''ll simply have to design a more robust capture mechanism.
The cooperative level dictates whether DirectInput relinquishes control when its window is not the foreground or focus window. That''s to allow it share access with other applications.
If you''re still using DirectInput for other purposes, you''ll simply have to design a more robust capture mechanism.
Author
well I found that it was the cooperation level of the keyboard. It was DISCL_EXCLUSIVE | DISCL_FOREGROUND, and this told me that it was so greedy that it did not even let WIN32 messages come through. So I changed it to NONEXCLUSIVE instead, and then the WIN32 messages started to work. Now everyone is playing nice and sharing.
thanks all for the help! much appreciative
thanks all for the help! much appreciative
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
