InKey( 0 ) - didn't sense keys such as CTRL+1

[Miroslav Georgiev]

Hi friends

?inkey( 0 ) did not sense keys from CTRL+0 to CTRL+9 at least under Windows. Did you notice this?

[Klas Engwall]

Hi Miroslav,

> ?inkey( 0 ) did not sense keys from CTRL+0 to CTRL+9 at least under
> Windows. Did you notice this?

Yes, and they are also not listed in inkey.ch and in tests\gtkeys.prg.
What results did you expect?

Clipper (at least under Win7 XP Mode with a Swedish keyboard driver)
produces some inkey codes, but most of them are 255.

Regards,
Klas

[Miroslav Georgiev]

Hi Klas. I'm using for example

?InKey( 0, INKEY_KEYBOARD + HB_INKEY_EXT )

The problem here is that no key press is detected at all.

That's not a scancode (inkey.ch) issue.

Tested with default US keyborad driver on Win10. 

[Klas Engwall]

Hi Miroslav,

> ?InKey( 0, INKEY_KEYBOARD + HB_INKEY_EXT )
>
> The problem here is that no key press is detected at all.
> That's not a scancode (inkey.ch) issue.

Scancodes are not the codes listed in inkey.ch but the codes the
keyboard sends when a key is pressed or a key is released. Those codes
are then interpreted by the keyboard driver (with for example different
results if the driver has previously detected the scan code for pressing
the Ctrl key but not yet for releasing the Ctrl key) and delivered to
the OS and further to the Clipper/Harbour runtime for conversion to
inkey codes.

There is a scan code table here: http://www.quadibloc.com/comp/scan.htm

Clipper does not convert the Ctrl-0 up to Ctrl-9 key presses in a
meaningful way. On the Swedish keyboard Ctrl-8 is the same key as Ctrl-[
because [ is really AltGr-8, and Ctrl-[ has the same inkey code as Esc
has, but some of the other keys mean nothing. So the result under
Clipper is probably a byproduct of the use of AltGr with certain number
keys for characters like {[]} in various regions of the world. In
Harbour those key presses are not interpreted/converted at all. I
suppose that is by design. That is why I asked what results you are
expecting. I don't see where those potential inkey codes could fit in
the inkey table except maybe as extended codes.

Regards,
Klas

[Miroslav Georgiev]

Hi Klas. Thanks - you are right - they're not scan codes.

The problem you explain sound to me like duplicated keys when standard inkey codes are used.

With extended codes keys are encoded more like code of "1" + modifiers - CTRL, ALT, SHIFT, etc..

here are more key combinations with no effect on Inkey (just sitting and waiting for a key.. and not sensing any keypress)

Keys such as CTRL+1, 2, 3, 4, ...

CTRL-ALT-A, B, C, D, ....

CTRL-ALT-1, 2, 3, 4, ....

all these key combinations are invisible for inkey. No keypress detected at all.

At the same time much less meaningful key as (numlock off) keypad 5 has is ok.

CTRL-SHIFT-DEL is also ok...

[Klas Engwall]

Hi Miroslav,

> Hi Klas. Thanks - you are right - they're not scan codes.
>
> The problem you explain sound to me like duplicated keys when standard
> inkey codes are used.

I just dug out the assembler sources of a keyboard driver I wrote way
back in the eighties based on info I found in various places at the
time, and I checked the row of the number keys (see the schematic
scancode illustration in the document I linked to yesterday). I found
that Ctrl plus one of those keys did not return anything useful there
either - usually 255 decimal, which is also what Clipper returned in
several cases when I tested in XP Mode yesterday. So it is possible that
there is nothing to pickup for the Harbour runtime from those key
combinations (I have not really searched for additional info about
keyboard drivers on the web, so things might have changed in the last
30+ years ... :-) )

> With extended codes keys are encoded more like code of "1" + modifiers -
> CTRL, ALT, SHIFT, etc..
>
> here are more key combinations with no effect on Inkey (just sitting and
> waiting for a key.. and not sensing any keypress)
> Keys such as CTRL+1, 2, 3, 4, ...
> CTRL-ALT-A, B, C, D, ....
> CTRL-ALT-1, 2, 3, 4, ....
> all these key combinations are invisible for inkey. No keypress detected
> at all.

The Ctrl + Alt combination is generally supposed to be translated to
AltGr, but I am not sure if it is entirey consistent. AltGr did not
exist at the time when I wrote my keyboard driver, so I do not have any
translation tables handy. And AltGr is only supported for keyboards with
three glyphs on the keytops and only for those keys.

> At the same time much less meaningful key as (numlock off) keypad 5 has
> is ok.

Probably because there is OS support readily available for it.

> CTRL-SHIFT-DEL is also ok...

The Grey keypad is supported in various combinations, but adding Ctrl or
Shift to Alt does not alter the Alt+AnyGreyKey inkey code, and adding
Shift to Ctrl does not alter the Ctrl+AnyGreyKey inkey code. But you can
check if one or more additional shift keys are pressed using
hb_gtinfo(HB_GTI_KBDSHIFTS) and branch accordingly in your application.
Or you can check the extended key code and its flags.

Regards,
Klas

[Miroslav Georgiev]

thank you very much