Alright. I''m using opengl for display, based at least roughly of these tutorials. In particular I tried to implement a bool keys[256] type keyboard monitering system. Problem is that it doesn''t appear to work correctly. I''ll post the relevant bits and pieces. Love to hear any ideas.
In windowproc:
case WM_KEYDOWN:
{
Input->KeyPress(wparam);
break;
}
case WM_KEYUP:
{
Input->KeyRelease(wparam);
break;
}
And the relevant parts of dginput class that Input is a member of:
It seems pretty straightforward to me and I''ve been unable to determine what is causing it to work incorrectly. So far as I can tell the values within keys[] never actually get changed. Any ideas?
Hmm. I hadn''t been real sure about what wparam was. So that clears that up. I made the change in my code as well, so KeyPress(), KeyRelease(), and QueryKey() all take (WORD key) as their parameter instead of an int. So that is closer to right. It still doesn''t work properly though. So far as I can tell the values of keys[] stay at what they are initialized at. I''ve tried to initialize them all to false and all to true to start with. Either way they remain in the state that they are originally set to in the constructer. Any ideas of why this might be happening?
I didn''t show it, but elsewhere i use QueryKeys() to update the camera position. So it checks A, S, D, W for forward, back, left, and right. If they start as true, and I comment out one of these checks (up, down, left or right), the camera will shoot in the opposite direction. So if I comment out up it sill shoot backwards. So this leads me to believe that when all the commands are there the camera sits still simply because by moving forward, back, left, and right equal distances it ends in the same spot. If on the other hand they start false, the camera never moves, regardless of whether or not all the checks happen to try to move the camera. So it seems to me from this that they aren''t being changed. Its not apparent to me why though. Either that or they are changing, but QueryKey() isn''t reading back proper values. Either way I''ve hit a brick wall here and I''m unsure how I should preceed...
Well, I had been using QueryKeys(''A'') and the like. But with an || QueryKeys(VK_LEFT). So I should have been safe and had it work one way or the other. Additionally, I tried changing to VK_A and the like and the compiler gaves errors, flagging them as undefined symbols. So then I changed them to just check for VK_UP, VK_DOWN, VK_LEFT, and VK_RIGHT. It doesn''t give errors for these, but the input still doesn''t affect the camera as it should. And I''ve looked through the camera code thoroughly enough to strongly believe that it is not where the problem lies. Thanks, its too bad it didn''t work yet. Anyone else care to try their hand?
case WM_KEYDOWN: { Input->KeyPress(wparam); break; } case WM_KEYUP: { Input->KeyRelease(wparam); break;}
Try removing the braces around the message handlers. I''m not sure, but I think that the break command jumps out of the smallest scope, and therefore in your WM_KEYDOWN handler, the break command is just jumping out of the braces and falling through to the WM_KEYUP command. I''m not sure if this is the case though. It seems like break might only jump out of loops. Try it anyway.
Place a breakpoint in your code and check to see what is going on or if you don''t have a debugger, place some messagebox calls in your code to report what is going on. Once you''ve found the problem it''s easy to remove those calls again. Works on pretty much anything that has to do with your own code.
I don't want to lecture or anything but when you implement a new class you should thoroughly test it before using that class in your programs.
The only thing I can think of is if you are using PeekMessage() in your message loop and you are removing the messages from the queue the windows messages ( WM_x ) basically never reach to the queue and that's why your keyboard is not responding properly, or at all.
Try calling PeekMessage with PM_NOREMOVE and see what happens.
Also, might be a bug in your program code and not the keyboard itself, that's why it's best to test the class before using it in your programs.
Get back to us with more info.
-Viktor
Edit: spelling.
[edited by - Gladiator on November 17, 2002 9:51:00 AM]
