Masked edit prevents access keys from being fired

[Josepth Badrouk]

Hello, 

I have a masked edit control with a mask of numbers only [1-9], and other controls on the screen that utilize access key shortcuts. When focused within the masked edit, the access keys do not get fired at all due to the mask only allowing numbers to be inputted. 

Is there a workaround to this, or is this a bug that can be fixed?

I've attached a video of a sample project demonstrating this. I have a button on the screen with an access key of ALT+E that should show a message box when the button is clicked. When within the masked edit, ALT+E is not working. When within the other textbox, ALT+E is working fine.

Sample:

<syncfusion:SfTextInputLayout Grid.Row="0">

    <syncfusion:SfMaskedEdit Mask="[1-9]"></syncfusion:SfMaskedEdit>

</syncfusion:SfTextInputLayout>

<syncfusion:SfTextInputLayout Grid.Row="1">

    <syncfusion:SfTextBoxExt></syncfusion:SfTextBoxExt>

</syncfusion:SfTextInputLayout>

<Button Height="50" Width="100" Click="ButtonBase_OnClick" Grid.Row="3">_Etest</Button>

Attachment: maskededit_607bb7d9.zip

[Karthick Arjunan]

Hi Josepth Badrouk, 

Sorry for any inconvenience caused. Access keys like Alt+E may not work when focus is inside the SfMaskedEdit control due to its input filtering behavior. To address this, we’ve handled the PreviewKeyDown event at the window level to manually detect and trigger the access key functionality, ensuring it works even when the masked edit is focused. We’ve attached a simple sample for your reference, please check the sample and let us know your concerns.

Regards,
Karthick Arjunan

Attachment: SfMaskedEditDemo_154f91a7.zip

[Josepth Badrouk]

Hello,

The sample provided is not an adequate solution. An application can have many access keys and we cannot simply check for each one individually at the window level. 

I believe the SfMaskedEdit is bugged in the sense that it is swallowing access keys from being processed and should be resolved to allow access keys to be processed to the AccessKeyManager, and not have to manually detect every ALT+key combination at the PreviewKeyDown event at the window level.

[Karthick Arjunan]

Hi Josepth Badrouk, 

We have confirmed the reported scenario is a defect and logged a report for the reported scenario, “SfMaskedEdit control restricts access key inputs when focused”. We will fix this issue and include it in our NuGet release which is scheduled for 07th October 2025.

 

You can track the status of this defect using the following feedback link: SfMaskedEdit control restricts access key inputs when focused in WPF | Feedback Portal

 

Please let us know if you need any further assistance.

Note: The provided feedback link is private, and you need to log in to view this feedback.

 

Disclaimer: “Inclusion of this solution in the weekly release may change due to other factors including but not limited to QA checks and works reprioritization.”

Regards,
Karthick Arjunan

[Karthick Arjunan]

Hi Josepth Badrouk,

We have included the fix for the reported issue “SfMaskedEdit control restricts access key inputs when focused” in our Weekly NuGet release version 31.1.21 which is available for download ( https://www.nuget.org/).

Root cause: When pressing the Alt key causes e.Key to return Key.System instead of Key.LeftAlt or Key.RightAlt, which leads to the Alt key being missed in key detection logic during OnPreviewKeyDown.

We thank you for your support and appreciate your patience in waiting for this update. Please get in touch with us if you require any further assistance.

Regards,
Karthick Arjunan