mIRC Home    About    Download    Register    News    Help

Print Thread
on keydown bug #245917 13/05/14 11:26 PM
Joined: Jul 2006
Posts: 3,729
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,729
I'm unsure if this is related but I'm getting similar problem.

I use a french azerty keyboard configuration, to generate some accentued letters, I must input a key for the accent first (for example the '^�' key, and then the letter. When pressing the '�^' key, on keydown triggers with a $keyval value of 24158 (the character is $chr(24158)) whereas when subclassing the window, no keydown event can be observed.
I'm using Windows 7 and mIRC 7.32, you can easily reproduce that by settings a french keyboard configuration (control panel > regions and languages > keyboard and languages > change keyboards.. select french and 'add', then use the left shift + alt shortcut to get that keyboard and hit the '[' key on a qwerty keyboard).


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: on keydown bug [Re: Wims] #266890 28/02/20 11:13 PM
Joined: Jul 2006
Posts: 3,729
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,729
Hello, this report received no attention, but the bug is there.

The issue is not relevant to the accent thing, you can simply put a french keyboard configuration and press altgr (aka control + alt) + 7.

On such configuration, you get nothing for the first keypress (just like with the '^' key situation i described), and any next keypress, regardless of what it is, will generate the correct character, in this case it's a `.

Inside on keydown, in this case, on the first keypress, I get some asian characters.

The correct behavior is to get 7 for $keyval and $null for $keychar.


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: on keydown bug [Re: Wims] #266899 29/02/20 07:00 PM
Joined: Jul 2006
Posts: 3,729
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,729
Quote
The correct behavior is to get 7 for $keyval and $null for $keychar.
The 7 should be sent as 55.

Others issue:

In a picture window with no editbox, control + c triggers on keydown with $keychar = $chr(22) and $keyval = 22 (6.35 used to return $chr(22) and 86 for $keyval, the uppercase 'v', there have been report about $keyval changing that way).
Control + v triggers with $keychar = $chr(3) and $keyval = 3.
I believe this is wrong. Pressing control always triggers with $keyval = 17, which is correctly VK_CONTROL, but once you add the 'c' or the 'v', the value are not correct.
22 is VK_IME_ON and 3 is VK_CANCEL, which doesn't seem to be correct?

The correct behavior for on keydown is probably to report the 'c' and 'v' keypress after reporting VK_CONTROL for the control key.
According to some google search it would even be advised that to catch control + c or v, one should check only for the letter being pressed, and then use $mouse.key to look for control being held down.


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: on keydown bug [Re: Wims] #267073 30/03/20 07:43 PM
Joined: Jul 2006
Posts: 3,729
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,729
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.


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: on keydown bug [Re: Wims] #267076 31/03/20 08:57 AM
Joined: Dec 2002
Posts: 4,841
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,841
Quote
The print screen key does not trigger the event

The print screen key does not generate a WM_KEYDOWN event, only a WM_KEYUP event.

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

mIRC does not wait for WM_CHAR or WM_DEARCHAR. The on KEYUP/DOWN events are triggered by WM_KEYUP/WM_KEYDOWN. These use the ToUnicode() API, which performs a conversion to set $keychar and, due to how ToUnicode() works, affects subsequent keyboard messages.

Thanks for your comments.

Re: on keydown bug [Re: Khaled] #267078 31/03/20 01:30 PM
Joined: Jul 2006
Posts: 3,729
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,729
Right, sorry I forgot about that.

Ok for printscreen, indeed.

Google is full of problem with ToAscii/ToUnicode killing/destroying dead keys with the exact same situation I'm describing.

It looks like the suggested workaround is to call the ToUnicode function twice with the exact same parameter, to eat any dead key if any.
You may be already using some kind of system like this for it since it does cycle between triggering on keydown and not triggering it, except it does it on the wrong keystroke.

However, as I've said, one cannot rely on $keychar (or $keyval anyway) in the on keydown event to get the resulting characters.
I was going to suggest that $keychar should probably be set only on the second key press of the dead key there, which mIRC could do, but I'm not sure it should, again even I knew I pressed a dead key and a vowel, i wouldn't know what to do based on the keys, msl doesn't provide the necessary tool to do the job, and I'm not asking for it, rather, I really hope you can add a new event which would trigger for WM_CHAR messages, what do you think of such feature?


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: on keydown bug [Re: Wims] #267172 13/04/20 12:15 AM
Joined: Jul 2014
Posts: 34
S
SykO Offline
Ameglian cow
Offline
Ameglian cow
S
Joined: Jul 2014
Posts: 34
Would waiting for WM_CHAR message to trigger the event cause any problems? would the delay be so big?

A new event would also be nice to fix this.

Re: on keydown bug [Re: SykO] #267174 13/04/20 07:25 AM
Joined: Dec 2002
Posts: 4,841
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,841
Quote
Would waiting for WM_CHAR message to trigger the event cause any problems?

Yes, they are very different.

The on KEYDOWN/KEYUP events return WM_KEYDOWN/WM_KEYUP keyboard presses. The WM_CHAR event returns actual characters after WM_KEYDOWN is triggered and the key press is translated and could be different to the non-translated key press. Some WM_KEYDOWN events do not generate any WM_CHAR events.

I may add an on CHAR event, however, even if I do, as a scripter, you may need to process both on KEYDOWN/KEYUP and on CHAR in your scripts. If your script is checking cursor key presses eg. for games, you will probably only need on KEYDOWN/KEYUP (cursor, and various other keys, do not generate WM_CHAR events). If you are trying to capture typed text, as in a text editor, you will need on CHAR. If you are trying to do both, your script will need to check all three events.

Re: on keydown bug [Re: Khaled] #267175 13/04/20 10:22 AM
Joined: Jul 2006
Posts: 3,729
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,729
Yes, I have stated in PM that it is undertstood for scripters that they would need to use one or the others two for the two differents features, keypresses and resulting chars.
I think they would be happy to, I'm really looking forward this addition.

In the past I made suggestions about having sizing/minimize/restore events inside menu { } definition, there's another feature that would be awesome to have, it's mouse wheel up/down event, I did test these last two with a dll to scroll a custom drawn list inside a picture window and it was working flawlessly. Given they are all windows messages, I think this could be part of a nice revamp and greatly improve picture windows.


Worth noting also that we can now access 3 more mouse events from on keydown with $keyval,
VK_MBUTTON 0x04 Middle mouse button (three-button mouse)
VK_XBUTTON1 0x05 X1 mouse button
VK_XBUTTON2 0x06 X2 mouse button

And here is an alias which convert $keyval value to meaningful text, it only works for keypress, not mouse button.

Code
alias keyvaltodesc {
  var %list 08 BACKSPACE.09 TAB.0C CLEAR.0D ENTER.10 SHIFT.11 CTRL.12 ALT.13 PAUSE.14 CAPS LOCK.15 IME Kana/Hangul mode.16 IME On.17 IME Junja mode.18 IME final mode.19 IME Hanja mode.19 IME Kanji mode.1A IME Off.1B ESC.1C IME convert.1D IME nonconvert. $+ $&
    1E IME accept.1F IME mode change request.20 SPACEBAR.21 PAGE UP.22 PAGE DOWN.23 END.24 HOME.25 LEFT ARROW.26 UP ARROW.27 RIGHT ARROW.28 DOWN ARROW.29 SELECT.2A PRINT.2B EXECUTE.2C PRINT SCREEN.2D INSERT.2E DELETE.2F HELP.30 0.31 1.32 2.33 3.34 4.35 5.36 6.37 7. $+ $&
    38 8.39 9.41 A.42 B.43 C.44 D.45 E.46 F.47 G.48 H.49 I.4A J.4B K.4C L.4D M.4E N.4F O.50 P.51 Q.52 R.53 S.54 T.55 U.56 V.57 W.58 X.59 Y.5A Z.5B LEFT WINKEY.5C RIGHT WINKEY.5D APPLICATIONKEY.5F COMPUTER SLEEP.60 NUMPAD 0.61 NUMPAD 1.62 NUMPAD 2.63 NUMPAD 3. $+ $&
    64 NUMPAD 4.65 NUMPAD 5.66 NUMPAD 6.67 NUMPAD 7.68 NUMPAD 8.69 NUMPAD 9.6A MULTIPLY.6B ADD.6C SEPARATOR.6D SUBSTRACT.6E DECIMAL.6F DIVIDE.70 F1.71 F2.72 F3.73 F4.74 F5.75 F6.76 F7.77 F8.78 F9.79 F10.7A F11.7B F12.7C F13.7D F14.7E F15.7F F16. $+ $&
    80 F17.81 F18.82 F19.83 F20.84 F21.85 F22.86 F23.87 F24.90 NUM LOCK.91 SCROLL LOCK.92 OEM.93 OEM.94 OEM.95 OEM.96 OEM.A0 LEFT SHIFT.A1 RIGHT SHIFT.A2 LEFT CONTROL.A3 RIGHT CONTROL.A4 LEFT MENU.A5 RIGHT MENU.A6 BROWSER BACK.A7 BROWSER FORWARD. $+ $&
    A8 BROWSER REFRESH.A9 BROWSER STOP.AA BROWSER SEARCH.AB BROWSER FAVORITES.AC BROWSER HOME.AD VOLUME MUTE.AE VOLUME DOWN.AF VOLUME UP.B0 MEDIA NEXT TRACK.B1 MEDIA PREVIOUS TRACK.B2 MEDIA STOP.B3 MEDIA PLAY/PAUSE.B4 LAUNCH MAIL.B5 LAUNCH MEDIA SELECT. $+ $&
    B6 LAUNCH_APP1.B7 LAUNCH APP2.BA OEM 1.BB OEM PLUS.BC OEM COMMA.BD OEM MINUS.BE OEM PERIOD.BF OEM 2.C0 OEM 3.DB OEM 4.DC OEM 5.DD OEM 6.DE OEM 7.DF OEM 8.E1 OEM specific.E2 OEM 102.E3 OEM specific.E4 OEM specific.E5 IME PROCESS.E6 OEM specific. $+ $&
    E9 OEM specific. EA OEM specific.EB OEM specific.EC OEM specific.ED OEM specific.EF OEM specific.F0 OEM specific.F1 OEM specific.F2 OEM specific.F3 OEM specific.F4 OEM specific.F5 OEM specific.F6 ATTN.F7 CRSEL.F8 EXSEL.F9 EREOF.FA PLAY.FB ZOOM.FD PA1.FE OEM CLEAR
  var %w $wildtok(%list,$base($1,10,16,2) *,1,46)
  tokenize 32 %w
  return $2-
}


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net