Same project, sometimes fn-ForwardArrow leads to a crash.
So, I wanted to test if fn key is depressed… but found nothing in the documentation (only that some KeyCode to be determined can return fn using a Command. Read Keyboard.)
I don’t have a Fn key to test with, so try this app and see what it says the Fn key code is when you press it: Key Codes · Many Tricks
1 Like
Fn key is a modifier key that usually does not fire a keycode. You press it AND another key and a mapped code for such combination fires (or not, unmapped combination). This way vendors sometimes maps some combination to bypass the keyboard IO and just affect hardware things as “disable the camera” or something.
Modifiers such as Command, Shift, Control and Option can be detected using Keyboard.AsyncKeyDown.
It should be a relatively quick test for anyone with a Mac and a Fn key. Unfortunately, I do not have a Fn key to test, otherwise I would have. If Key Codes.app shows a KeyCode for it, then I would expect there to be a Xojo KeyDown that can be trapped.
On my extended wired Apple keybaord, Fn by itself is not detected. 2018 Mini, Sonoma 14.6.1
Edit: however, it must be detectable somehow, because if, in the System Settings, I set Fn to (say) “Show emojis …”, then pressing Fn toggles the visibility of the Emojis panel on the display.
Edit: System Settings → Keyboard → Keyboard Shortcuts → Modifier Keys and set Fn key to (say) Escape. Then pressing Fn shows the Esc key in Key Codes.
1 Like
I know that some keys, like the media keys (Previous Track, Next Track, Pause, usually embedded in the F[0-9]+ keys), reach the system but not the application layer. That’s where Apple’s “Do as I say, not as I do.” comes in, and it’s sometimes a thing we can’t* do.
On a MacBook Pro the fn button is also the world button. The world button, pressed on its own, changes the keyboard layout (assuming you have more than one defined).
In terms of fn-forward arrow it works as follows:
Just Right Arrow
Key Down
Characters:
Unicode: 63235 / 0xf703
Keys: →
Key Code: 124 / 0x7c
Modifiers: 10486016 / 0xa00100 ⓘ
fn-Right Arrow
Key Down
Characters:
Unicode: 63275 / 0xf72b
Keys: 
Key Code: 119 / 0x77
Modifiers: 8388608 / 0x800000 ⓘ
fn on it’s down produces, as captured by Tim’s suggested “Key Codes - Many Tricks” app:
Modifier Change
Modifiers: 8388864 / 0x800100 ⓘ
I got the same results as @Ian_Kennedy, except I’m using a Logitech MX Keys mini for Mac keyboard, with an iMac (M3).
Pressing just fn by itself does not show anything in the Key Codes app.
Same with shift, control, option or command. These keys only register when in commendation with a character key and only some media/function keys.
Dealt with this years ago. The fn key is handled by the keyboard’s firmware and does not generate any events detectable to the OS without being combined with another keypress.
Standard caveat that you should not use AsyncKeyDown in a KeyDown event. The Keyboard CommandKey, ControlKey, etc record the state of those keys when the event was fired. That state may have changed in the interim.
1 Like
That’s true. However, my point was just responding to Rick, that many modifiers do have a keycode.
How does that work when I remap Fn to (say) Escape? Then I press Fn by itself and Key-Codes reports Escape.
I believe the remap function is not done at the OS level but done within the keyboard firmware itself. That is how they get a universal key remap even in apps like games that attempt to poll the keyboard hardware directly. This is only true on MacOS and not on Windows afaik.
Edit: It does make me curious as to how they handle this with third party keyboards. Perhaps it’s not the actual keyboard firmware and more the EFI/BIOS’s code when dealing with keyboard input. “Firmware” was the word that was used when it was explained to me though.
As I say the Apple fn button is used by itself without any other key to change the keyboard layout in use. For example, UK or Chinese keyboard etc.
Keyboard driver, a driver is a layer between the OS and a hardware. It knows things and do things that the OS may have no idea. ANY key is known by the driver, it knows the key location and status (pressed/unpressed) but don’t know if the user see an “L” or a “Ç” printed on the surface of it. Those codes are known as scancodes. Then another layer comes in, the keyboard layout and key mappings, that translates the physical keys to logical keystrokes. This is at the OS level, and the user can choose one. The keyboard driver is king, it potentially can make things like talking directly to other drivers of that vendor instead of sending any code to the OS. A wrong driver kills a keyboard or some functionality, A different driver on a different OS version may send “Fn” modifier code (not standard, Fn is not meant to send scancodes) or just keep quiet waiting for a combination keypress to send some expected standard scancode to the OS, or just doing nothing.
https://aeb.win.tue.nl/linux/kbd/scancodes-1.html#ss1.12
My MacBook Pro went to sleep while I was eating and I press the fn key to wake it up !
As said earlier, this is a modifier key and as such have to be tested using Keyboard.
Extract from the Documentation:
This is the only place where that key appears: Keyboard.Keyname.
Now, your opinion is worth mine. I use that with the Delete Key to get the other Delete, with some Arrow Key (top / bottom)…
And the reason of this entry was because Xojo trap a Key without the Modifier and my code crash (unlike with other software, including the IDE).
Ian: can you share URL(s) of Apple document(s) about how to change the Keyboard Layout using the fn key ?
Coincidentally, in a Mac, Apple is the writer of their driver. They can make your mac burn to ashes pressing Fn if they want. 
But probably any keyboard driver author would call a system wake up if possible from the driver too.
If I ask (how to use it) it is because I use it; it is not a fad.
I’m not understanding you now.
But just for information, in my keyboard, the keydown event isn’t fired for the Fn key
I’ve researched and found the Xojo reports the Xojo Keyname for Fn as Integer 63 here.
Never intercepted, by any means, including a
If Keyboard.AsyncKeyDown(63) then break
In a timer.
So the behavior of being able to intercept it is probably very machine/OS/Version specific.
I also have no idea on how this breaks your app, It would great a very small sample able to reproduce your crash, and the community could find what may be wrong in your design or you have something very specific going on in your machine.