Acmlm's Board - I2 Archive - Programming - WM_KEYDOWN Issue
| User | Post |
beneficii
Posts: 432/567 |
OK, implementing. |
Dish
Posts: 539/596 |
Quite a thing? It's only like 4 lines of code. You already have a message pump, just clear a 'busy' var when there are no messages pending, check the 'busy' var before doing lengthy work, and set the 'busy' var when you start doing lengthy work.
Anyway, there are other ways to do it. All you have to do is figure out a way for your program to tell itself that it's too busy to do the requested workload. Another way to do this would be to flush the message queue after you finish with lengthy work so that any repeat messages are discared ... although this will toss all other messages as well -- such as quit requests and other crap (so I don't recommend it)
Really, this way isn't that hard.
By the way, no need to quote my entire post if you're just replying with a single liner  |
beneficii
Posts: 431/567 |
Originally posted by Disch
the WM_KEYDOWN repeat rate is one of the user preferences set in Windows (the speed can be changed in one of the control panels), so no, you're program can't (or at least shouldn't) try to change the speed at which WM_KEYDOWN messages are sent.
The obvious solution here sounds to me like you should just not process WM_KEYDOWN messages if your program is too far behind. This could be done by doing some checks in your message pump:
MSG msg;
int ok_to_sleep;
while( program_open )
{
ok_to_sleep = 1;
while( PeekMessage( your_wnd, &msg, 0, 0, PM_REMOVE) )
{
TranslateMessage(&msg);
DispatchMessage(&msg);
ok_to_sleep = 0;
}
program_busy = 0; // queue is clear, program is no longer busy
if(ok_to_sleep)
Sleep(1);
}
Then in your ChangePipeSets function or whatever.. just do a check to see if the program is busy before continuing:
void ChangePipeSets()
{
if(program_busy) return; //abort, program is too busy
program_busy = 1; //this will make the program busy
// do the rest of the work here
}
This seems like quite a thing to implement. Is there any simpler way? |
Dish
Posts: 538/596 |
the WM_KEYDOWN repeat rate is one of the user preferences set in Windows (the speed can be changed in one of the control panels), so no, you're program can't (or at least shouldn't) try to change the speed at which WM_KEYDOWN messages are sent.
The obvious solution here sounds to me like you should just not process WM_KEYDOWN messages if your program is too far behind. This could be done by doing some checks in your message pump:
MSG msg;
int ok_to_sleep;
while( program_open )
{
ok_to_sleep = 1;
while( PeekMessage( your_wnd, &msg, 0, 0, PM_REMOVE) )
{
TranslateMessage(&msg);
DispatchMessage(&msg);
ok_to_sleep = 0;
}
program_busy = 0; // queue is clear, program is no longer busy
if(ok_to_sleep)
Sleep(1);
}
Then in your ChangePipeSets function or whatever.. just do a check to see if the program is busy before continuing:
void ChangePipeSets()
{
if(program_busy) return; //abort, program is too busy
program_busy = 1; //this will make the program busy
// do the rest of the work here
}
|
beneficii
Posts: 430/567 |
I have an issue when the user holds down a key for too long. When pipes are loaded in my SMB3 Map Editor, you can switch between various pipe sets with the page up and page down keys (which are read through the WM_KEYDOWN message). When you press one of them, it unloads the old pipe set and loads the new one and draws it to the screen. Unfortunately, if the user tries to go through the pipe sets by holding page up/down, then the program will freeze. My guess is that the window is receiving the keyboard input that is too fast for it to handle, and so it locks up. Is there a way of slowing down this input for the window when the user holds it down (without making the user go to the control panel to slow it down and without changing it for the whole system) or is there some other way around this?
Thanks. 
UPDATE: I tried putting them under WM_KEYUP, but doing it too fast still causes it to freeze up. |
|
