New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ClosedApple + <key> is not working (when using right ALT key) #558

Closed
tomcw opened this Issue May 29, 2018 · 13 comments

Comments

Projects
None yet
2 participants
@tomcw
Contributor

tomcw commented May 29, 2018

The right ALT key (aka Alt Gr) works, but the key it's combined with (eg. "A") is not made available to $C000 / $C010.

This isn't a regression (I went as far back as 1.13.1) - it appears never to have worked!

NB. The erroneous way that AKD works (#330) means that if I press "A", followed by right ALT + "A", then $C010 (AKD) will go high. (EDIT: but only for this "A" key, not for any other keys.)

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jun 30, 2018

Contributor

At 1.27.5.0, then (when right ALT is down) the internal keycode doesn't get updated when any keys are pressed. So if keycode=13, then (when right ALT is down), any key press (eg. "A") will cause AKD/$C010 to return 141 (ie. 13+128).

Contributor

tomcw commented Jun 30, 2018

At 1.27.5.0, then (when right ALT is down) the internal keycode doesn't get updated when any keys are pressed. So if keycode=13, then (when right ALT is down), any key press (eg. "A") will cause AKD/$C010 to return 141 (ie. 13+128).

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jul 1, 2018

Contributor

Some logging showing the difference in Windows message received for left vs right ALT:
(ext = lparam.KF_EXTENDED, joy = JoyProcessKey() indicated that the key-press was for a joystick input)

Left ALT+A
WM_KEYDOWN = 0x12, ext=0, joy=1
WM_KEYDOWN = 0x41, ext=0, joy=0
WM_CHAR    = 0x61

Right ALT+A
WM_KEYDOWN = 0x11, ext=0, joy=0
WM_KEYDOWN = 0x12, ext=1, joy=1
WM_KEYDOWN = 0x41, ext=0, joy=0
WM_CHAR    = 0xE1

Right ALT+B
WM_KEYDOWN = 0x11, ext=0, joy=0
WM_KEYDOWN = 0x12, ext=1, joy=1
WM_KEYDOWN = 0x42, ext=0, joy=0

Right ALT+C
WM_KEYDOWN = 0x11, ext=0, joy=0
WM_KEYDOWN = 0x12, ext=1, joy=1
WM_KEYDOWN = 0x43, ext=0, joy=0

So when right ALT is pressed, then in general WM_CHAR is not sent.
In fact WM_CHAR is only sent for these right ALT+<key> key-strokes:

Keyboard key WM_CHAR wparam Character in Notepad++
` 0xA6 ¦
A 0xE1 á
E 0xE9 é
I 0xED í
O 0xF3 ó
U 0xFA ú
$/4 0x80

Also see https://en.wikipedia.org/wiki/AltGr_key

Contributor

tomcw commented Jul 1, 2018

Some logging showing the difference in Windows message received for left vs right ALT:
(ext = lparam.KF_EXTENDED, joy = JoyProcessKey() indicated that the key-press was for a joystick input)

Left ALT+A
WM_KEYDOWN = 0x12, ext=0, joy=1
WM_KEYDOWN = 0x41, ext=0, joy=0
WM_CHAR    = 0x61

Right ALT+A
WM_KEYDOWN = 0x11, ext=0, joy=0
WM_KEYDOWN = 0x12, ext=1, joy=1
WM_KEYDOWN = 0x41, ext=0, joy=0
WM_CHAR    = 0xE1

Right ALT+B
WM_KEYDOWN = 0x11, ext=0, joy=0
WM_KEYDOWN = 0x12, ext=1, joy=1
WM_KEYDOWN = 0x42, ext=0, joy=0

Right ALT+C
WM_KEYDOWN = 0x11, ext=0, joy=0
WM_KEYDOWN = 0x12, ext=1, joy=1
WM_KEYDOWN = 0x43, ext=0, joy=0

So when right ALT is pressed, then in general WM_CHAR is not sent.
In fact WM_CHAR is only sent for these right ALT+<key> key-strokes:

Keyboard key WM_CHAR wparam Character in Notepad++
` 0xA6 ¦
A 0xE1 á
E 0xE9 é
I 0xED í
O 0xF3 ó
U 0xFA ú
$/4 0x80

Also see https://en.wikipedia.org/wiki/AltGr_key

@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Jul 1, 2018

Contributor
Contributor

sicklittlemonkey commented Jul 1, 2018

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jul 2, 2018

Contributor

Hi Nick,
Thanks for those links.
The first one is interesting:

Don’t reinvent the wheel: avoid the temptation to use the keyboard information functions (MapVirtualKeyEx and related functions) to reimplement the WM_KEYDOWN -> WM_CHAR translation.

Since AltGr doesn't generate a WM_CHAR message, then there has to be some manual translation to convert an AltGr-generated WM_KEYDOWN (+ SHIFT) to an ascii value. Since we now have to do this, then we could ditch support for the WM_CHAR message in AppleWin, and just always manually translate WM_KEYDOWN.

Contributor

tomcw commented Jul 2, 2018

Hi Nick,
Thanks for those links.
The first one is interesting:

Don’t reinvent the wheel: avoid the temptation to use the keyboard information functions (MapVirtualKeyEx and related functions) to reimplement the WM_KEYDOWN -> WM_CHAR translation.

Since AltGr doesn't generate a WM_CHAR message, then there has to be some manual translation to convert an AltGr-generated WM_KEYDOWN (+ SHIFT) to an ascii value. Since we now have to do this, then we could ditch support for the WM_CHAR message in AppleWin, and just always manually translate WM_KEYDOWN.

@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Jul 2, 2018

Contributor
Contributor

sicklittlemonkey commented Jul 2, 2018

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jul 3, 2018

Contributor

Heeding the "don't reinvent the wheel" advice, I will try posting a WM_KEYDOWN message without the extended (AltGr) flag set, so that TranslateMessage() will post a WM_CHAR. This seems like a simpler approach.

Another reason is that in Keyboard.cpp, for the TK3000e machine, there's support for accented chars (ie. wparam>127). If I were ditching WM_CHAR then (after switching it to WM_KEYDOWN) I'd need to test this code, but I don't want the time sync of having to go near this code!

Contributor

tomcw commented Jul 3, 2018

Heeding the "don't reinvent the wheel" advice, I will try posting a WM_KEYDOWN message without the extended (AltGr) flag set, so that TranslateMessage() will post a WM_CHAR. This seems like a simpler approach.

Another reason is that in Keyboard.cpp, for the TK3000e machine, there's support for accented chars (ie. wparam>127). If I were ditching WM_CHAR then (after switching it to WM_KEYDOWN) I'd need to test this code, but I don't want the time sync of having to go near this code!

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jul 27, 2018

Contributor

I will try posting a WM_KEYDOWN message without the extended (AltGr) flag set, so that TranslateMessage() will post a WM_CHAR.

This didn't work - no WM_CHAR message was generated.

So instead I manually post a WM_CHAR message, on getting WM_KEYDOWN for ascii keys (accounting for shift, control & caps lock).

Also pressing Alt Gr sends WM_KEYDOWN messages for VK_LCONTROL and VK_RMENU. This fake VK_LCONTROL masks whether Control is really being pressed or not. So I'm suppressing this fake VK_LCONTROL in the keyboard hook filter.

Contributor

tomcw commented Jul 27, 2018

I will try posting a WM_KEYDOWN message without the extended (AltGr) flag set, so that TranslateMessage() will post a WM_CHAR.

This didn't work - no WM_CHAR message was generated.

So instead I manually post a WM_CHAR message, on getting WM_KEYDOWN for ascii keys (accounting for shift, control & caps lock).

Also pressing Alt Gr sends WM_KEYDOWN messages for VK_LCONTROL and VK_RMENU. This fake VK_LCONTROL masks whether Control is really being pressed or not. So I'm suppressing this fake VK_LCONTROL in the keyboard hook filter.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jul 27, 2018

Contributor

On my Microsoft PS/2 keyboard, when I press Alt + AltGr + key, then for these keys I never get a WM_KEYDOWN message:
(I've tried to lay them out as they are spaced on the keyboard)

      W        [
     A D  G  J '#
    \   CV  N   /

Which is probably a limitation of the keyboard.

NB. When using NumPad for joystick emulation, then pressing '0' + '.' + key is fine for all keys on the keyboard.

Contributor

tomcw commented Jul 27, 2018

On my Microsoft PS/2 keyboard, when I press Alt + AltGr + key, then for these keys I never get a WM_KEYDOWN message:
(I've tried to lay them out as they are spaced on the keyboard)

      W        [
     A D  G  J '#
    \   CV  N   /

Which is probably a limitation of the keyboard.

NB. When using NumPad for joystick emulation, then pressing '0' + '.' + key is fine for all keys on the keyboard.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jul 27, 2018

Contributor

Merge PR #573 / 6ed3547

Contributor

tomcw commented Jul 27, 2018

Merge PR #573 / 6ed3547

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Jul 29, 2018

Contributor

In #570, Marco reported that on his Italian(?) keyboard, AltGr+<key> is used to type #, @, [ , ] keys. And Wikipedia shows this too, here.

I said:

There isn't much demand for ClosedApple+, so maybe I'll provide a GUI option for opting in to this new 1.27.6 behaviour, and revert so that the default is like 1.27.5 (and earlier).

Contributor

tomcw commented Jul 29, 2018

In #570, Marco reported that on his Italian(?) keyboard, AltGr+<key> is used to type #, @, [ , ] keys. And Wikipedia shows this too, here.

I said:

There isn't much demand for ClosedApple+, so maybe I'll provide a GUI option for opting in to this new 1.27.6 behaviour, and revert so that the default is like 1.27.5 (and earlier).

tomcw added a commit that referenced this issue Jul 29, 2018

Keyboard:
. reverted default so that ALT+TAB is not hooked (#556)
. reverted default so that ALT GR's fake LCONTROL is not hooked (#558)
. added new switches: -hook-alt-tab and -hook-altgr-control to support hooking these key combo's (#556)
@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Aug 6, 2018

Contributor

There's a new 1.27.7 release here with the hooked ALT GR fake LCONTROLreverted.
Use -hook-altgr-control if you really need to do Closed Apple+CTRL+<key>!

Contributor

tomcw commented Aug 6, 2018

There's a new 1.27.7 release here with the hooked ALT GR fake LCONTROLreverted.
Use -hook-altgr-control if you really need to do Closed Apple+CTRL+<key>!

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Aug 12, 2018

Contributor

A summary of what changed at 1.27.7:
(NB. Before 1.27.7, for Closed Apple + <key>, the <key> wasn't visible via $C000 or $C010.)

  • Closed Apple + <key> now working for both $C000 and $C010 (AKD).
  • Closed Apple +CTRL + <key> only working if you use -hook-altgr-control.
  • Open Apple + Closed Apple +CTRL + <key> only partially working if you use -hook-altgr-control.
    • Workaround: use NumPad '0' + '.'
  • Open Apple + <system key> working (may need to use a cmd line switch) - see #556.
Contributor

tomcw commented Aug 12, 2018

A summary of what changed at 1.27.7:
(NB. Before 1.27.7, for Closed Apple + <key>, the <key> wasn't visible via $C000 or $C010.)

  • Closed Apple + <key> now working for both $C000 and $C010 (AKD).
  • Closed Apple +CTRL + <key> only working if you use -hook-altgr-control.
  • Open Apple + Closed Apple +CTRL + <key> only partially working if you use -hook-altgr-control.
    • Workaround: use NumPad '0' + '.'
  • Open Apple + <system key> working (may need to use a cmd line switch) - see #556.
@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Aug 12, 2018

Contributor

Closing this issue, since the current (1.27.7) support for Closed Apple + <key> is probably good enough.

Contributor

tomcw commented Aug 12, 2018

Closing this issue, since the current (1.27.7) support for Closed Apple + <key> is probably good enough.

@tomcw tomcw closed this Aug 12, 2018

@tomcw tomcw added this to the 1.27.7 milestone Aug 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment