Some feedback about this..
$keylparam was added to solve the problem of telling if right or left shift/control/alt was pressed (ignoring left alt, which does not trigger).
The problem, as shown in the code i posted above, is that the shift key does not use the the 'extended' 24th bit to tell for left/right, it uses the scan code and the function MapVirtualKey(), which we can't make use of, so for shift, it doesn't solve the problem.
I don't think it was good idea to report the lParam value to us but/and this shows its limit.
This is what it offers us:
- bit Explanation
- 0-15 The repeat count for the current message. The value is the number of times the keystroke is autorepeated as a result of the user holding down the key. If the keystroke is held long enough, multiple messages are sent. However, the repeat count is not cumulative.
- 16-23 The scan code. The value depends on the OEM.
- 24 Indicates whether the key is an extended key, such as the right-hand ALT and CTRL keys that appear on an enhanced 101- or 102-key keyboard. The value is 1 if it is an extended key; otherwise, it is 0.
- 25-28 Reserved; do not use.
- 29 The context code. The value is 1 if the ALT key is held down while the key is pressed; otherwise, the value is 0.
- 30 The previous key state. The value is 1 if the key is down before the message is sent, or it is 0 if the key is up.
- 31 The transition state. The value is 1 if the key is being released, or it is 0 if the key is being pressed.
0-15 is already there via $keyrpt
16-23 without accessing the window api, i'm not sure what we can do with it, same as what i described at the beginning of this post.
24 can help use telling between right alt and right control but not right shift.
29 is not applicable because if alt (left) is held down, nothing trigger
30 could be used but in most practical purpose knowing this information is not that useful i'd say
31 not sure if applicable.
So I don't think knowing lParam is that great for scripter, especially if it does not provide a way to tell for the shift key.
However, VK_RSHIFT/VK_LSHIFT are proper values we can check against the table
here, same for control and alt.
The function I posted in my previous post should be used to report the correct keypress from the start imo. Yes it would change the value of $keyval, breaking compatibility, but it must be said that the 'recent' fix for on keydown with the addition of on char to correctly reports keypress and resulting characters means that on keydown's $keyval (and $keychar) were never working correctly to begin with, and there have been a couple of report regarding $keyval and $keychar not reporting the correct value anyway, so the idea there is a 'compatibility' for $keyval is a bit compromised.
If backward compatibility were to be preserved, well there is still the shift issue. $keylparam support can be kept, but i'd remove it if it were meant to solve the right shift/alt/control key as it does not fully solve that. And i'd just follow what i said in my previous post.
