[ANSWERED] Detect if the Fn key is pressed

[CM630]

Is it possible to detect if the Fn key, available in some keyboards is pressed?
Here is what is present in classesh.inc:

Code: Pascal  [Select][+][-]

1. { Types used by standard events }
2.   TShiftStateEnum = (ssShift, ssAlt, ssCtrl,
3.     ssLeft, ssRight, ssMiddle, ssDouble,
4.     // Extra additions
5.     ssMeta, ssSuper, ssHyper, ssAltGr, ssCaps, ssNum,
6.     ssScroll,ssTriple,ssQuad,ssExtra1,ssExtra2);

There is no Fn in it.


I just saw, that Fn + something generates VK_Something. It seems to solve the case.

[winni]

Hi!

Put an Edit component on a form an press an Fn key:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Edit1KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState );
2.     var msg ,s: String ;
3.     sh : TShiftStateEnum;
4. begin
5. msg := '';
6. for sh in  Shift do
7.   begin
8.     writeStr(s,sh);
9.     msg := msg + s +' / ';
10.   end;
11. msg := msg + LineEnding+IntToStr(key);
12. showMessage(msg);
13. end;                                      

Winni

[rvk]

The Fn usually doesn't have a scancode.
https://stackoverflow.com/a/2778020

If it does return one, it might not on other systems.
The Fn changes the scancode of other keys.

[winni]

The Fn usually doesn't have a scancode.
https://stackoverflow.com/a/2778020

If it does return one, it might not on other systems.
The Fn changes the scancode of other keys.

That is also visible with my code sniplet.

Winni

[rvk]

That is also visible with my code sniplet.

Apparently, according to that topic, it could give a non-standard scancode, depending on the system/keyboard. I just wanted to clarify that because you can't rely on it if it gives you one.

[MarkMLl]

Apparently, according to that topic, it could give a non-standard scancode, depending on the system/keyboard. I just wanted to clarify that because you can't rely on it if it gives you one.

OP hasn't told us the operating system(s) in which he is interested.

My experience is that that sort of thing is likely to vary by widget set, and to potentially be messed up if going through any sort of remote control connection.

On a PC, it might- or might not- be intercepted by either hardware or by System Management Mode code and used solely to generate a "real" scancode at BIOS level, i.e. way below any application or even operating system involvement.

MarkMLl

[rvk]

I just saw, that Fn + something generates VK_Something. It seems to solve the case.

Of course does pressing Fn + function key generate VK_functionkey. That's how it works.
But you didn't detect if it was pressed with an Fn key. You just detect if the function key (F1..F12) is pressed.

If that was all you where after, you didn't need to ask about the Fn key because that doesn't matter.

On some keyboards you need to press Fn in combination with F1..F12 to reach those function keys. Otherwise you get other functions. For the ultimate scancodes which you receive from the keyboard, it doesn't contain information if it was in combo with Fn.

BTW. If you don't like the Fn key, some systems let you disable it in the BIOS so that pressing the F1..F12 will directly activate the key as function key.(without the Fn).

[PascalDragon]

On a PC, it might- or might not- be intercepted by either hardware or by System Management Mode code and used solely to generate a "real" scancode at BIOS level, i.e. way below any application or even operating system involvement.

It's likely not at the BIOS level, but at the level of the keyboard itself. E.g. my tablet has a keyboard that can work both directly connected (USB through pogo pins) or through bluetooth and it uses a function key as well. In short: don't expect to be able to determine the state of the Fn key.

[MarkMLl]

On a PC, it might- or might not- be intercepted by either hardware or by System Management Mode code and used solely to generate a "real" scancode at BIOS level, i.e. way below any application or even operating system involvement.

It's likely not at the BIOS level, but at the level of the keyboard itself. E.g. my tablet has a keyboard that can work both directly connected (USB through pogo pins) or through bluetooth and it uses a function key as well. In short: don't expect to be able to determine the state of the Fn key.

Remember that the BIOS is very much in play even with modern OSes, since it's there- in conjunction with SMM- that power on/off, volume control etc. buttons are handled.

MarkMLl

[CM630]

I just saw, that Fn + something generates VK_Something. It seems to solve the case.

Of course does pressing Fn + function key generate VK_functionkey. That's how it works.
But you didn't detect if it was pressed with an Fn key. You just detect if the function key (F1..F12) is pressed.

Ooops, yes.

Here is the values of key that I get:

  Fn+F1 = 18
F1 = 112

  Fn+F8 = 178
  F8 = 112

  Fn+D = 68
  D = 68

It seems that the keyboard generates some extra KEY values only for combiantion of Fn+Fx. In all other cases the Fn is ignored.
But oddly, when I tried to associate Fn to a shortcut on the desktop of Win10, when I press Fn+C Windows captured it as ctrl+alt+C. But when I press Fn+C the shortcut is not launched. It gets launched when I press ctrl+alt+C.

So it means that Windows detects somehow that Fn is pressed.

In Lazarus procedure TForm1.Edit1KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); gets triggered when I press Alt or Ctrl (without another key), but it is not triggered when I press Fn only.

There is nothing in the BIOS for that key, it is a standalone keyboard attached to a desktop PC.

[PascalDragon]

But oddly, when I tried to associate Fn to a shortcut on the desktop of Win10, when I press Fn+C Windows captured it as ctrl+alt+C. But when I press Fn+C the shortcut is not launched. It gets launched when I press ctrl+alt+C.

That is because shortcuts must use Ctrl+Alt. Windows only received the C and added the Ctrl+Alt itself.

[rvk]

So it means that Windows detects somehow that Fn is pressed.

No, it means the keyboard just sends a different scancode to the computer when that Fn is pressed in combo. The Fn itself is not send.

The computer doesn't even know it's dealing with a keyboard which has a Fn key.

Scancode 178 is KEY_MEDIA_STOP
Scancode 119 is F8
See https://www.appgamekit.com/documentation/guides/scancodes.htm

The computer doesn't know these are on the same key. On another keyboard they could be separate keys. So it's just the keyboard which decides what to send to the computer.

[winni]

Hi!

To be more exact: It is up to the keyboard driver.
If you know how to write a keyboard driver you could change the behaviour.

A good description is here:

https://stackoverflow.com/questions/24423724/finding-the-scan-code-of-fn-key

Winni

[rvk]

To be more exact: It is up to the keyboard driver.
If you know how to write a keyboard driver you could change the behaviour.

That would depend on the keyboard.
If the keyboard doesn't send out a scancode for Fn alone, everything is done inside the keyboard.

Otherwise my function keys won't work on my old DOS machine, which they do (without driver).

[MarkMLl]

Hold on: Are we talking about the function keys F1  through F12, which have scancodes even if they don't have (ASCII) character codes, or the special Fn key on laptops. etc that is used to enable function and special keys when they're shared with ordinary ones?

I was assuming the latter, i.e. the key literally marked "Fn", which wasn't even common during the DOS era.

MarkMLl