LiveCode Forums.

Good morning.

I would like to use the Type command, not to simulate a keyboard press of "A" or else, but of a function key, like "F1" or "F2".
The F1 key returns on my Mac keyboard, on RawKeyDown, 65470.
I tested but then, trying to intercept it in RawkeyDown it doesn't work (I get a bunch of numbers).
Also using on functionKey theKey, does not works.

So, the all idea is use Type to simulate the F1 key press and be able to detect, on my script, if this F1 key has been pressed.
Thanks for any help.

Hi.

I was pretty sure that it would be fruitless, and was right, at least for me.

Function keys are "control" keys, like the optionKey or the commandKey. They are very difficult to integrate into the "normal" LC world. They stand apart as a group which gives them a certain special status which is hard to break into. Anyway, trying to finagle the "functionKey" and "keysDown" functions defeated me entirely. I could not simulate a user keyPress on F1. Just as I could not with, say, the controlKey. One can see its state, but not simulate a keypress on it.

I think.

Someone may chime in with a clever method, and if so, that would force me to go back quite a ways in this forum to see if the many other queries along this line could then be worked out.

The good news is that you can do whatever you need without having to rely on a script-controlled keypress on a function key. Just do the task somewhere else in the usual way, and abandon the need to simulate that keyPress.

Easy for me to say.

So is there some reason, apart from that you think it a nice idea, to have to use a function key?

Craig

Trevix, what would you like the Function key trigger to do?

Sorry: I always try not to be too verbose, but I alway end up having to explain what the hell I am doing....

We are talking about Bluetooth HID protocol.
I am experimenting on sending, from a Nordic chip, a string with I capture on LC with "KeyDown", in mobile devices.
The string is composed like this (comma delimited): My LC routine, which is placed in a "front" script, detects the 1st character (StartChar):
If it is the "decided start char", then the KeyDown collects the rest of the string, up to the ending char (EndChar) and does something with the received string.
If not, it passes the KeyDown to whatever the user is typing.

The BT device sends each value chosen from a HID table (see https://gist.github.com/ekaitz-zarraga/ ... 5a5723969b).
Must be noted that unfortunately the value received IS NOT a char num, BUT a keyboard position.
In order to not interfere with the normal text input of a user in my standalone, the StartChar must be unique and something that a casual user will never type (not even in a password).

This thing works fine, as long as I use one of the keyboard keys that doesn't change position according to the language: the key "1" doesn't seems to change position if I use a keyboard set to Italian or USA, or French, etc (don't know yet about QUERTY and DVORAQ).
But special chars move around with the change of language, except, perhaps, a few ones, like the F1,F2 etc (this is the reason of my FunctionKey choice).

Probably, using a defined sequence of chars, instead of a single one, as a Startchar, could solve my problem. But it would add a lot of complexity to my routine and I would like to avoid it.
Remember that in the standalone the user will have plenty of input fields, scrolling etc, that should work without a glitch.

Being my script so dangerous for a normal use of a standalone, I must be sure that it works fine in any situation and be able to debug it in the IDE. This is why I am using the "Type" command to do simulation on my Mac.

I hope to have explained myself well enough.
Then if you want to know why I need to do all this, that will require another long explanation

Let's pause for a moment and meditate on keyboard position . . .

I assume by 'BT' you mean British Telecom, and I assume British Telecom 'knows' only about a GB-English keyboard layout.

AND, not (as you noted) the Dvorak keyboard layout:
- -

However, if I have my keyboard layout set to DVORAK, when I press the 'e' key I get the SAME keyDown signal as when I press the 'e' key on the layout I generally use (US - English).

Therefore key position should not matter; at least insofar as one in dealing with Roman key layouts.

So:

1. Your LC stack should receive a signal informing it of which key, where on the keyboard, has been pressed.

[ noticed that the HID table you rerefenced is 8 years old: does that matter? Maybe not. ]

It should be a relatively easy exercise to run up a conversion table of those codes (e.g. 0x04) to their Unicode values . . .

BUT, if, for the sake of argument chummy (our end-user) hits an 'र' ( as a very large number of people in England originate in the subcontinent and use Hindi a lot because of the British government's lack of effort at any sort of cultural integration, the possibility of an 'र' is probably quite high ) . . . all you need is a series of lookup tables to work out that 'that' (in the standard Devanagari keyboard layout at least) is the same as hitting the 'r' key on a bog-standard GB-as-far-as-the near-sighted-BT-engineers-can-twist-their-minds keyboard . . .
- -
Yup: this WILL involve quite a bit more work than "Effing" the F-keys, but it might be a better bet.

- -
Hitting the same key in the GB - English, and the Devanagari keyboard layouts (MacOS 15 beta) yield the SAME rawKey values, so who gives a flying fudge what chummy's keyboard layout is?

Most of what I wrote above is redundant: all you need is an equivalency table for key positions and rawKey values.

Wonky effort:
-

@Trevix.

I am not sure I understand how the position of keys among the several possible keyboard variations matters in your use case.

So I latched onto a sentence in your second post:

In order to not interfere with the normal text input of a user in my standalone, the StartChar must be unique and something that a casual user will never type (not even in a password).

So does that not mean that you could select one of the many "untypeable" (and also unprintable) chars in the upper ASCII set?

@Everybody. So does this indeed mean that function keys are "control" keys, and live hermit lives inaccessible per se via script?

Craig

@Richmond: in italy BT is mostly used for Bluetooth (at least in between programmers)

I am not sure if I can explain this, but I will try:
The Bluetooth device sends 0x3a and 0x3b as StartChar and EndChar (F1 and F2), with other data in the middle.

Apparently the RawKeyDown is not affected by the chosen keyboard language, always receiving 65470 and 65471. Fine.
The chars in the middle instead "do" get changed (try Chinese).
When transmitting a MAC address, the numbers (1,2,3..) stay the same (on KeyDown) but the letter codes (a,b,c) are changed because what is receive in KeyDown is the key position, not the ascii code or whatever.
If the Nordic sends "0x04" for letter "A", if your phisical chosen keyboard has "B" where I have "A", you receive "B".
I know, is very confusing. I guess the HID standard just added to the mess.

I was able to arrange my script so that it should work, with a mixture of RawKeyDown and KeyDown, but as for debugging on the Mac with the "Type" command, I gave up.
Thanks all.