Archived

This topic is now archived and is closed to further replies.

PhenixDarkPhire

Disabling Keyboard auto-repeat

Recommended Posts

As I''ve already posed in a topic on text input in general, I''m having problems with the sensitivity of the keyboard when testing for input using WM_CHAR. I have tried all of the following with no avail: 1) Tested to see whether the character had been just pressed, or was being held down using the lParam - (if(!(lParam & 0xc0000000)) 2) Used the SystemParametersInfo function to set SPI_SETKEYBOARDSPEED and SPI_SETKEYBOARDDELAY to the lowest possible values 3) Created an array of booleans to represent the virtual keys setting them to true using WM_KEYDOWN and false using WM_KEYUP, sending the character input only on the initial WM_KEYDOWN I''m exasperated. Any help at all would be greatly appreciated.

Share this post


Link to post
Share on other sites
If i understand you correctly, then what you want to do is use your array of booleans (very handy). Set the key to true when it is pressed (KEYDOWN). When your code checks to see if the key is down, and finds that it is (because the value is true for that key) set the boolean to false. On subsequent passes when it checks that key, it will see that false and believe the key is up and will no longer process that key until you press it again.

I wrote a nifty wrapper that will handle all that for you, can email it to you if you don''t understand what i said (its late and i''m bad at explanations).

Share this post


Link to post
Share on other sites
Would you not need another flag per key to tell whether the key is still down but has been dealt with? ie:

press key, generate WM_KEYDOWN
in WM_KEYDOWN set down flag and clear dealt flag

When you check for down flag, check dealt flag and perform command if it is false. After command has been dealt with set dealt flag to true and leave down flag as is (true) otherwise the next WM_KEYDOWN will cause the down flag to be set again, thereby giving you the problems with repeating as you described.

Code:
// Initial state for all keys is down=false,dealt=false

// when user presses key and generates first WM_KEYDOWN
if (not keys[wParam].down) and (not keys[wParam].dealt) then
begin
keys[wParam].down := True;
keys[wParam].dealt := False;
end;{if}

// when checking for keydown
if keys[wParam].down and (not keys[wParam].dealt) then
begin
// do your thang
keys[wParam].dealt := True;
end;{if}

// and finally in WM_KEYUP
keys[wParam].down := False;
keys[wParam].dealt := False;

Hope this helps.

--
Cheers,

[edited by - eSCHEn on October 23, 2003 3:22:42 AM]

Share this post


Link to post
Share on other sites
I did things a little differently, but essentially that''s exactly what I did. I used 2 sets of booleans (one to indicate key state up/down and one to indicate whether that keystroke had already been dealt with). The problem is, I process with the WM_CHAR function, and test with the WM_KEYDOWN function. The WM_CHAR and WM_KEYDOWN messages return different values, so there''s virtually no way to test for something both in WM_KEYDOWN and WM_CHAR and get the same value. I think what I may try to do is use the ToAscii function in the WM_KEYDOWN message and leave WM_CHAR out altogether. Does anybody know how to use that function or have any other advice?

Share this post


Link to post
Share on other sites
Breakthrough, ladies and gentlemen. But it still doesn''t work perfectly. I found a way to convert the wParam passed during a WM_CHAR event into a Virtual Key, like the wParam passed by WM_KEYDOWN and WM_KEYUP events. In this way, I was able to find a universal (sort of) value to use in a boolean function. The only problem is, since the range of characters is greater with the WM_CHAR event, any character created using the shift key (ie extended characters) can only be used once. After this, I assume the WM_CHAR processing causes the boolean to show that the character has not yet been released, and the WM_KEYUP event does not handle those characters. If I can find a way to get WM_KEYUP to produce those results, or limit the power of the WM_CHAR function, I should be able to solve the problem. Any ideas?

Share this post


Link to post
Share on other sites