Jump to content
Mike Warren

[FMX beginner] Key Handling

Recommended Posts

I've been using Delphi since 1996, but have been fixed at D7 for many years. I've finally upgraded to D11.3 and am creating my first FMX based application, targeting Win64 and Android64.


I added an ActionList and added an Action with a shortcut of Alt+X.


The problem I have is that the Alt+X key press triggers a windows beep sound.


This is something I do regularly in VCL based apps. As soon as an action with a shortcut is defined the Windows beep does not fire.


How do I fix this in a FMX based app?


Share this post

Link to post

Hi !

- D7 VCL to D11.3 FMX : what a huge jump. 😉 ! 

- just tested under a blanck 11.1 fmx app : I do not have the problem. Event trigered without system beep (I put just a showMessage in the event ).

Could you teste in a same way under 11.3 ? (blanck app)

- Have you something special in the event ? 

Share this post

Link to post

Thanks for the reply Vincent.


To duplicate this, do the following:

1/ Create a new blank multi-device application

2/ Add an ActionList component

3/ Add an Action the the ActionList

4/ Set the Shortcut for this action to Alt+X

5/ In the OnExcecute event of the Action, add Close;


Run the program and press Alt+X. The program will close and a Windows Beep will be heard.


Do exactly the same thing with a VCL program and no beep is heard.


All this on D11.3 and Windows 11



Share this post

Link to post
Posted (edited)

if fact, the "BEEP" came from OS messages, not any Delphi components, like ActionList or anyother... VCL or FMX

you can try "supress" all beeps using a "windows API"...

  • NOTE: in my VCL (empty) project or FMX (empty) project... pressing ALT + any_key  = BEEP!!!
    • then, does not matter if VCL or FMX = beep always sounds

{$R *.fmx}


procedure TForm1.Action1Execute(Sender: TObject);

// Disable system beep
  SystemParametersInfo(SPI_SETBEEP, 0, nil, SPIF_SENDWININICHANGE); 

// Enable system beep
  SystemParametersInfo(SPI_SETBEEP, 1, nil, SPIF_SENDWININICHANGE);



Edited by programmerdelphi2k
  • Like 1

Share this post

Link to post

Thanks for your reply. I don't want to disable the system beep globally.


With a VCL based application, anything (Action, Button etc.) that has a shortcut assigned to it will prevent the key message for the shortcut being passed on to Windows so Windows will not play its default beep.


The same behavior can be seen by adding a button instead of an action and setting the button's Text (Caption) property to &X.


This is starting to look like a bug in FMX to me, or at least missing functionality.


Share this post

Link to post
3 hours ago, programmerdelphi2k said:

for me, be VCL or FMX always I have a beep...

Well, they shouldn't, and don't for me. VCL applications behave correctly, as they have done since D1 (yes, I've been using Delphi that long). FMX application process the keystrokes and then pass them to Windows. It should not do this.

Here's a video demonstrating the issue.


Share this post

Link to post

That seems to be not OK. Also if one use a TTabControl and have some tabitems on it (eg &Test and &BTest) then the selection of this items with Alt+T or Alt+B works, but there is a beep.

Perhaps it would be worth to make a Quality report... 

Share this post

Link to post
Posted (edited)

in  fact, ALT+any-key beeps happens same that your app has just 1 form and nothing more... in RAD 11.3 here (VCL or FMX)  :classic_ohmy:

Edited by programmerdelphi2k

Share this post

Link to post

It's normal to get a beep for Alt+key combinations that are not handled by the application, but it the app handles the key combination it should be swallowed by the app so Windows doesn't get it. VCL has always done this.

I'll make a quality report.

Share this post

Link to post

Very annoying, I've also voted. Has anyone found a workaround?

Share this post

Link to post
14 hours ago, MrZ said:

Very annoying, I've also voted. Has anyone found a workaround?

I'd love to know if there is a workaround too. My program is still in development, but I cannot release it with such a bug. That would be very unprofessional behavior. I go to a lot of trouble to make my applications as bug free as possible.

If this is not fixed by the time I get close to release I will need to find a workaround myself.

Share this post

Link to post

Also, my report was closed as it's considered a duplicate.


Please vote on https://quality.embarcadero.com/browse/RSP-33860


I see this was reported as far back as 10.3. I really don't understand how almost every Delphi FMX developer is not being caught by this. Do Delphi developers just accept unprofessional behavior from their applications?


Share this post

Link to post


I guess noone uses shortcuts anymore. Especially FMX applications tend to be distributed for Android or iOS. No shortcuts there...only gestures and taps. So this might really be an oversight due to lack of use.

Share this post

Link to post
Posted (edited)

I put a bit of time into this and found where the messages are being passed to Windows in FMX.Platform.Win.


As a quick and dirty test I copied FMX.Platform.Win to my project source folder and made some modifications to it.


1/ I created a global variable I called SuppressWM_SYSCHAR.

2/ In my form's KeyDown event I checked if Alt plus a letter was being pressed, and if so, I set SuppressWM_SYSCHAR to true.

3/ At line 837 I check SuppressWM_SYSCHAR and if false I allowed DispatchMessage(Msg); to be called

4/ A timer set to 50mS in my form would reset the SuppressWM_SYSCHAR back to False


I discovered that this also suppressed menu accelerator keys.


I then compiled for MacOS and discovered that shortcuts using Alt+ also cause a system beep there. I also discovered that the Alt+ keys generate different message codes under MacOS.


It was at this point that I decided to scrap the whole idea of using Alt+ keys for any shortcuts on button activation since these don't work on MacOS anyway.


I changed any shortcuts to not use Alt+ alone.


I feel defeated by this and just cannot afford to put any more time into trying to understand it.


Edited by Mike Warren

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now