zpq
New Member
Posts: 18
|
Post by zpq on Sept 30, 2021 12:44:14 GMT -5
does not work for BACKSPACE key.
|
|
|
Post by tsh73 on Sept 30, 2021 13:25:27 GMT -5
works OK for me
Never heard someone complaining about this. How one could use debugger if (if/end if) does not work?
EDIT
now THAT's different
I just printed all codes, not only 1-byte ones In normal mode, backspace produces two messages: (0 8) and (8) While in debug mode, only (0 8)
So you still could catch it. But why it works so different I have no idea.
|
|
|
Post by Rod on Sept 30, 2021 15:17:52 GMT -5
The backspace key issues two events one on key down one on key up. Several keys do this. So your code sees one but not the other because you only test for a single character string response. The first key down is ignored because it is two in length and first character 0.
In debug you react to each character so you don't react. In run time you see the first (08) and ignore it, loop round and handle the second (8). So there are quirks to the keyboard. In fact the keyboard and all its shift states is quite complex. Just keep printing out the FULL string and ask values till you get a feel for it.
|
|
|
Post by Walt Decker on Sept 30, 2021 17:46:47 GMT -5
If you use a mult-line edit control with the ES.WANTRETURN style you can monitor all of the "weird" keys with User32.dll function GetKeyState(); other keys that have an ansi value > 30 can be monitored directly via various LB... messages.
|
|
|
Post by Brandon Parker on Oct 1, 2021 12:43:49 GMT -5
GetAsyncKeyState() is also another option since it will tell you not only the status of the key being checked, but also whether or not that key was activated since the previous call to GetAsyncKeyState(). GetAsyncKeyState Function on MSDNCallDLL #user32, "GetAsyncKeyState", keycode As long, _ result As short {:0) Brandon Parker
|
|
zpq
New Member
Posts: 18
|
Post by zpq on Oct 4, 2021 10:43:57 GMT -5
|
|
|
Post by Rod on Oct 4, 2021 14:00:39 GMT -5
Well that is kinda half a solution. While the keyboard wil produce the virtual key code 8 it will also produce 08,8
While the code works for you there are still nuances that might catch you out. Key down, key up, one character response, two character response.
Just be aware it is a bit more complex than using the virtual key code which in any event is just 8
|
|
|
Post by Walt Decker on Oct 4, 2021 14:11:41 GMT -5
There is a fair MSWNI API resource at WIN API
|
|
|
Post by Rod on Oct 4, 2021 14:32:46 GMT -5
I think we are missing the key part of this discussion. We started with reading keys in debug. This requires focus and the key pressed while the program is awaiting an event.
So far so good. But that is only half the answer. The program whether in debug or running normally may get two events from the backspace key press. An event when it goes down and an event when it is released. Either 08 or 8.
Now think about your handler. Is it reading two characters or one. If you look for 08 you will only get one event handled. If you look for the right most character which indicates the key, not the shift state, you will get two events 08 and 8 and the danger is you backspace twice. Once on key down once on key up. So your handler needs to look for either 08 or a single character 8.
Lots of examples of reading the keyboard use the rightmost character if the response is two characters. That’s fine but carries the danger of reacting twice. It is most often seen with the enter key which also gives key down key up events.
Just something to be aware of, know that the keyboard messages can be of variable length and occur more than once. Set your handler to suit.
|
|