Skip to content
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

Right Alt Key ignored by inkey()/LastKey() #239

Open
Hovestar opened this issue Apr 6, 2021 · 8 comments
Open

Right Alt Key ignored by inkey()/LastKey() #239

Hovestar opened this issue Apr 6, 2021 · 8 comments

Comments

@Hovestar
Copy link

Hovestar commented Apr 6, 2021

In inKey() (on windows 10) the right alt key is ignored.

For example:
while !((nLast:=inkey(0, INKEY_KEYBOARD))==27) // escape
? nLast,lastKey()
enddo

Pressing left alt + g gives
290 290
g gives
103 103
right alt + g gives
103 103
left ctrl + g gives
7 7
Right ctrl + g gives
7 7

We've noticed on multiple machines, and the same code in xHarbour gives proper results.

@alcz
Copy link
Contributor

alcz commented Apr 6, 2021

Which keyboard layout is set on those Win10 machines? US?
Is it GTWIN terminal?
Also for some layouts "right Alt" equals "left Ctrl+left Alt", what would it do with "g"?

@Hovestar
Copy link
Author

Hovestar commented Apr 6, 2021

US, and no other keyboards installed.
Pressing "left Ctrl+left Alt + g" doesn't even trigger inkey(). The docs mention that ctrl+alt doesn't work: https://harbour.github.io/doc/harbour.html#inkey

@Hovestar
Copy link
Author

Hovestar commented Apr 6, 2021

However that's distinct behavior from right alt g where it just gives the code that g would normally give.

@alcz
Copy link
Contributor

alcz commented Apr 7, 2021

I've made some tests, but not having US layout here. Both on Win7 and Win10.
right Alt + g doesn't work, nor left Alt + left Ctrl + g - both do not generate any scan code, one can use only left Alt + g
No difference with sample run by old xHarbour 1.0.0 - the only one i have here.

You can build keybord test app from the repo too:
https://github.com/harbour/core/blob/master/tests/gtkeys.prg

There is also a registry based solution for mapping right alt to work exactly like left one. With SharpKeys utility or without.
https://stackoverflow.com/a/460800

@Petewg
Copy link
Member

Petewg commented Apr 26, 2021

Hi,
you may want to take a look at this thread:
https://groups.google.com/g/harbour-devel/c/8Sc9YI5hnDE/m/eAn9Q9zGBAAJ
not sure, but perhaps could be relevant with the issue in question.

@Hovestar
Copy link
Author

That looks like exactly this issue. I'll see what I can do with that to resolve the issue.

For my reference look at commits related to these:
druzus - Jul 4, 2016, 1:19:03 PM
druzus - Jun 29, 2016, 5:05:09 PM
2016-06-20 21:59 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)

Thanks, I'll detail a solution here once I get one.

@Hovestar
Copy link
Author

After extensive debugging this is an intentional feature gtwin.c:~1700:

if( iChar >= 32 &&
      ( ( ( iFlags & HB_KF_CTRL ) != 0 && ( iFlags & HB_KF_ALT ) != 0 ) ||
      ( dwState & ( LEFT_ALT_PRESSED | RIGHT_ALT_PRESSED ) ) == RIGHT_ALT_PRESSED ) )
{
   iFlags &= ~( HB_KF_CTRL | HB_KF_ALT );
   iKey = HB_INKEY_NEW_CHARF( iChar, iFlags );
}
else
   iKey = HB_INKEY_NEW_KEY( iChar, iFlags );

I assume that this is a choice for international support, but I think it would be nice to have some way to turn this logic off. I'll leave the issue open for a day or two, and if there's nothing else on it I'll come close it.

@alcz
Copy link
Contributor

alcz commented Apr 28, 2021

Perhaps we could add some US/International modes into (sort of reused) HB_GTI_KBDALT with the current mode as default.
hb_gtInfo( HB_GTI_KBDALT, HB_GTI_KBDALT_US / HB_GTI_KBDALT_INTL )

With those added to hbgtinfo.ch:

/* Keyboard Right-ALT US mode */
#define HB_GTI_KBDALT_INTL      0
#define HB_GTI_KBDALT_US        1

Will see if I can make a patch that is not awful, because HB_GTI_KBDALT used to have logical paramters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants