LiveCode Forums.

Dear All,

the background is that I'm trying to create some keyboard shortcuts, ideally, using an Alt key combination.

The following script works as expected with both the left 'Alt' key and the right 'Alt Gr' key giving the appropriate resonse However, if I then try and add another key (101 - 'e') as below: the left Alt key is unresponsive but I get an expected response from the right 'Alt Gr' key.

I can't make sense of this to enable a fix.

(If I use the Ctrl key everything works as expected but is more tricky to implement due to clashes with system Ctrl shortcuts!

Just wanted to check if any windows users out there had any thoughts or ideas?

Many thanks,

Regards,

Glenn

Have you tried using optionKey instead?

Hi.

I don't use Windows, for obvious reasons.

On a Mac the "alt" key is the control key, though LC makes no distinction. This gives the same result, left or right button: Craig

I'd guess that the two alt keys have different keycodes. Use Richmond's stack to see if that's the case and if so, alter the handler to account for both variations.

Macs don't have an altGr key so I can't test it for you.

dunbarx wrote: ↑

Fri Feb 11, 2022 6:59 pm

Hi.

I don't use Windows...

On a Mac the "alt" key is the control key...

I use Windows almost daily.

The Mac equivalent is the Option key. The Windows Control key is functionally equivalent to the Mac Command key.

I suggested Glenn try using optionKey instead of altkey because if there's a bug with how LC is handling both Alt keys it's less likely to also affect the Option key mapping. Most LC engine devs use Mac and most LC customers choose LC for its cross-platform capabilities, so Option key mappings likely get more attention.

Yep, "option" key, not "control", I have options, but little control.

Craig

My laptop on which I run Xubuntu GNU-Linux has an 'Alt Gr' on the right and an 'Alt' on the left:

Alt = 65513

Alt Gr = 65514

So I'd just stick with rawKey codes and not bother with altKey, optKey or camelToe.

The modifier key functions exist specifically to avoid having to look up specific key codes, with the aim of maintaining the goal of usability.

Of course if there's a bug with optionKey as there appears to be with altkey, then there's no choice but to use the catch-all workaround of raw key codes.

But before we decide that distinguishing usability features don't work, it may be worth trying them.

I don't think it's a bug, just a misunderstanding of how the handler should work. I replied in another thread:
viewtopic.php?f=7&t=30813&start=45#p212938

Edit: Now that I'm at the computer I see the issue. I think Richmond's right and the handler needs to check the keycodes. I also wonder if both altkey types should respond the same way, or if there's a good reason to differentiate.

Richmond, or anyone.

How did you get the option (alt) key to return a value as a parameter of the "rawKeyDown" message? None of the "control-type" keys on a Mac return anything at all. I can check to see if they are down, but cannot see a "value" for them.

Craig

Aha. Just read the dictionary. Mac systems do not send the message. Hmmm, I do not like that at all.

Craig

FourthWorld wrote: ↑

Fri Feb 11, 2022 8:28 pm

dunbarx wrote: ↑

Fri Feb 11, 2022 6:59 pm

Hi.

I don't use Windows...

On a Mac the "alt" key is the control key...

I use Windows almost daily.

The Mac equivalent is the Option key. The Windows Control key is functionally equivalent to the Mac Command key.

I suggested Glenn try using optionKey instead of altkey because if there's a bug with how LC is handling both Alt keys it's less likely to also affect the Option key mapping. Most LC engine devs use Mac and most LC customers choose LC for its cross-platform capabilities, so Option key mappings likely get more attention.

Thanks Richard.

Tried the Option key but unfortunately no luck, the code reacted again with a 'Alt Gr' response!

Regards,

Glenn

jacque wrote: ↑

Fri Feb 11, 2022 7:11 pm

I'd guess that the two alt keys have different keycodes. Use Richmond's stack to see if that's the case and if so, alter the handler to account for both variations.

Macs don't have an altGr key so I can't test it for you.

Hi Jacque, thank you - with Richmond's stack both the 'Alt' and 'Alt Gr' are both showing the same '65513' keycode! Regards, Glenn

The Macintosh Option key is functionally equivalent to the Windows Alt Gr key,
if you want the equivalency of the Windows Alt key you'll have to use a keyDown statement.
- -
Sorry, List Mum: that was just impossible to resist.

richmond62 wrote: ↑

Fri Feb 11, 2022 9:16 pm

My laptop on which I run Xubuntu GNU-Linux has an 'Alt Gr' on the right and an 'Alt' on the left:

Alt = 65513

Alt Gr = 65514

So I'd just stick with rawKey codes and not bother with altKey, optKey or camelToe.

Hi Richmond,

interesting that Linux distinguishes between the Alt and Alt Gr with different key codes. Using your stack on my PC I get the same keycode with Alt and Alt Gr, ie 65513, although my understanding is that the 'Alt Gr' is combination of 'Alt + Ctrl'?!

Looks as though I'll need to stick with my 'Ctrl' key combinations workaround for now!

Regards,

Glenn