LiveCode Forums.

This sort of 'magic' goes on if one plays around with a Korean keyboard layout:
- -
The 3rd field is the numToCodePoint of the top field.

I'm still not sure what these rawKey numbers are actually based on? I mean these larger numbers that get returned, beyond the base ASCII set of characters. Are they standards keyboard 'scan codes' based? Or 'virtual key codes'''? Based on some extended character encoding number set such as classic Mac Roman? When I check these numbers against various lists, I can't make these numbers in the 6500s (multi-byte) range match any of the numberings I've found in various lists of keyboard scan codes and the like.

Here's a PDF of a list of these numbers returned from rawKeyDown . that I had collected at one point, produced by a newer Aluminum Apple US Keyboard :
https://github.com/PaulMcClernan/LiveCo ... 0CODES.pdf

I image this issue with international keyboards not placing the '=' character could be easy to work-around by adding to main stack script a rawKeyDown script which translates / forwards it as the desired character like so:

Thank you Paul for your answer, and for the PDF document.

I was unable to make your script work, even by replacing the focusedControl with focusedObject.

But this one seems to work, even in the script editor, and it could be a workarround:

Zax wrote: Fri Mar 29, 2024 9:06 am Thank you Paul for your answer, and for the PDF document.

I was unable to make your script work, even by replacing the focusedControl with focusedObject.

But this one seems to work, even in the script editor, and it could be a workarround:

Code: Select all

on rawKeyDown pKey
   if (pKey = 65469) then
      if (the selectedChunk <> "") then
         put "=" into the selection
      end if
   else pass rawKeyDown
end rawKeyDown

Glad to help.

I'd still like to know where exactly did these particular numbers come from when they were added to the engine.

these particular numbers

are in theory Unicode glyph addresses, and MOST of the time LiveCode behaves itself and interprets them as such (otherwise my Devawriter Pro would not work).

HOWEVER, while the number pad on the right-hand side of extended keyboards and F-keys do deliver what should be Unicode glyph addresses, LiveCode (and the OS in general) interprets them differently (hence my earlier reference to 'magic').

'Magic' (in the computer world at least) generally boils down to finding out what was going on in "Fred Flintstone's" head when he was programming the bit of code that results in the difficulty we are having.

If you feel a desperate urge you can find the rawKey codes for ALL the function keys and so on and then pop over to the Unicode consortium's website and look them up: believe me, I did this for an awful lot of writing systems, and developed quite a few fairly entertaining headaches doing so. Recently used two enormous exercise books full of Unicode addresses and fancy symbols from fancy languages to light the living-room fire.

THIS is NOT the problem.

The problem (such as it is) is that the OP is having a 'bad day' insofar as LC doesn't seem to love his keyboard (actually it is probably NOT a problem with his keyboard as he has tried a few of them, but, either what the OS on his machine does with a particular keyDown, or what LC does with is.

The claim (backed up by others) is that the combination of MacOS and a non-English language keyboard does not deliver an '=' to LC when the '=' is pressed on the number pad of those Mac keyboards. The claim is made more complicated by the fact that pressing on the '=' on the number pad in, say, TextEdit or LibreOffice DOES deliver an '=' sign.

So . . . my first question would be:

1. On an English language layout keyboard pressing the '=' on the number pad delivers the raw key code of 65469: ss that the raw key code delivered on a French AZERTY Mac keyboard?

1.1. If the answer is 'No', then the problem probably lies in LC insofar as MacOS will pick up "Wot Ever" from the '=' on the number pad regardless of what type it is (QWERTY, AZERTY, @#$%^&, and so on) and deliver an '=', while LC seems onbly able to do that with QWERTY keyboards.

My first question has already been answered: and the answer is 'Yes'.

So my second question is this:

2. Does LC detect what type of keyboard is connected to a computer, and for the sake of argument, differentiate between a QWERTY and an AZERTY in such a way that it responds differently whan the '=' is pressed on the number pad?

2.1. If the answer is 'Yes' then we need to ask if that is necessary? Does it have effects elsewhere? And if the answer to that one is 'No' the code that differentiates between keyboard types needs to be removed.

At this time, we probably have too many unknowns to better target the cause of the problem.
We would need to find other people with an extended non-QWERTY keyboard (i.e. with a numeric keypad to the right of the alpha keypad).

Have you tried using the Number Lock key?
- -
c'est étrange, mais je n'ai pas un difference entre quand le clé est enforcée est né.

Excusez-moi pour ma langue "Franglais."

J'ai ein kartoffel im munde.

richmond62 wrote: Thu Apr 11, 2024 11:36 am...
J'ai ein kartoffel im munde.

richmond62 wrote: Thu Apr 11, 2024 11:36 am Have you tried using the Number Lock key?

Nice try... but try again as the lock key has no effect on my = problem

richmond62 wrote: Thu Apr 11, 2024 11:36 am c'est étrange, mais je n'ai pas un difference entre quand le clé est enforcée est né.

Hum, oui, cette phrase est assez étrange... please don't tell me my english is so weird

The capsLock key, like all the other "control" keys, has no rawKeyDown value.

But am I missing something? The rawKeyDown parameter for the "=" key on my extended keyboard is "61", and on the "=" key at the keypad is "65469".

What is the issue?

Craig

dunbarx wrote: Thu Apr 11, 2024 2:43 pm The capsLock key, like all the other "control" keys, has no rawKeyDown value.

But am I missing something? The rawKeyDown parameter for the "=" key on my extended keyboard is "61", and on the "=" key at the keypad is "65469".

What is the issue?

Craig

I think this is incorrect, CapsLock does have a rawKey Value (see the PDF list I posted), although I can't recall now exactly how I arrived at that number, I think is was while playing around with command+option+shift+FKey combinations.

And also these 2-byte ranged numbers are not the same as the unicode (utf-16) numbers.

Paul.

Not the first time I have been wrong, but if I place this in the card script: and start typing, I get values almost everywhere except for what I call the "control" keys, for example, the option key, the shift key and also the Caps lock key.

How did you get a value?

Craig

Paul.

Is is possible you are referring to the fact that if one gets rawKey values as one types, that if the caps lock key is down then that value changes to reflect the case of the typed value itself? if so then that is not a value of the caps lock key itself.

Why do I think you did not make this mistake? So how did you get any value at all, and what was it?

Craig

dunbarx wrote: Thu Apr 11, 2024 4:40 pm Paul.

Is is possible you are referring to the fact that if one gets rawKey values as one types, that if the caps lock key is down then that value changes to reflect the case of the typed value itself? if so then that is not a value of the caps lock key itself.

Why do I think you did not make this mistake? So how did you get any value at all, and what was it?

Craig

It may also have been while playing around with combinations of evaluate script, possibly mixed with LCB syntax, while working on my on-screen-keyboard widget.

Try this with some of those special key combos: It seems the keysDown is the plural form of getting the first param of the 'on rawKeyDown' handler, which seems like an error in the naming of that engine property (hence my comment), it would be nice if there were an equivalent for the plain text name/char of the keys that are down in a chord, but there isn't.

Paul.

Well, well.

Caps Lock - 65509
Shift - 65505
Control - 65507
Option - 65513
Command - 65511

And of course if you have ALL of them down when you hit any other key, you get ALL of them in a comma delimited list. Nothing really new there, of course. So those keys do indeed have a numerical value, it is just that you cannot get that value with what I used to think was the ultimate tool to do so, "rawKeyXXX", to find them.

Well, well.

Craig