Thanks a lot for looking into it.

Feedbacks:

The print screen key does not trigger the event, otherwise, all keys on my keyboard report correct values for individual single key press for $keyval, nice.


It must be noted that for example, before, control + A would produce (when pressing the A, otherwise it's 17 for control, that was already ok before) $keyval = 1 as well as $keychar = $chr(1), it now produces $keyval = 65 and $keychar = $chr(1).
The WM_KEYDOWN message for A does not have the code point '1', only 65, so mIRC must be waiting for the WM_CHAR message before triggering on keydown, since that message has the value mIRC is reporting for $keychar.

However some control + letter are not triggering the event, if control + A, works, control + F doesn't, they seem to correspond to mIRC's shortcuts, but most of them are still reporting the key correctly.

When pressing the '^' key, i should first get nothing, I stated in the first post that I checked at the time, and no WM_KEYDOWN message can be seen, that wasn't correct.
Since pressing that key once does produce a WM_KEYDOWN, it's normal to trigger on keydown.
Now it seems that mIRC tries to handle the WM_DEADCHAR, or at least tries to handle dead keys:
-What happens in a typical windows's editbox is you press '^' once, get nothing, press another key, and get something (it can be two characters if you type '^' and then not a vowel for example)
-But on keydown triggers for the first keypress of '^', and it's for the second keypress that it doesn't trigger, and then cycle like that (WM_DEADCHAR should not be handled to handle dead keys, there nothing that must be done to handle dead keys but to use WM_CHAR, which we can't access yet).

For example, the WM_KEYDOWN message for the first keypress only contains the value of the key press, which is 221, but mIRC reports a $keychar value of $chr(94).
It must be noted that the first keypress also does NOT generate a WM_CHAR message, only a WM_DEADCHAR after the WM_KEYDOWN, and that WM_DEADCHAR has the value 94.

It is clear to me that mIRC waits for WM_CHAR and WM_DEADCHAR in both control + a and the '^' situation to set $keychar

It looks like it would be better if mIRC were not using the value of WM_DEADCHAR for $keychar, and simply reported $null for $keychar in this case

It also looks like when mIRC sees a WM_DEADCHAR message, it will not use the next WM_CHAR value for the $keyval identifier, instead it uses the:
I press '^' once then i press 'o', mIRC reports $keychar = 'o' instead of 'รด', despite getting WM_CHAR 244.
If I could guess how mIRC could get the value so far, in this case I don't know because it only seems to get '79' for the press of the 'o', with the WM_CHAR message being 244, is it possible that mIRC is also using an ANSI call there to get the character?


However if mIRC is waiting for WM_CHAR and WM_DEADCHAR (among others things) to trigger the on keydown event, it does look like it is achieving both purpose at the same time: reporting keypress and resulting characters, which is good.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel