Allow custom event onkeydown handlers for all input components #1288

New Issue

claunia · 2026-01-29T17:51:40Z

claunia commented

2026-01-29 17:51:40 +00:00

Originally created by @standbych on GitHub (Jul 9, 2024).

Describe the bug
It's not possible to use any custom onkeydown handlers anymore, because of the @onkeydown:stopPropagation added for https://github.com/radzenhq/radzen-blazor/pull/1379.

To Reproduce
Steps to reproduce the behavior:

Add a RadzenNumberic component
Add @onkeydown event handler
run and press any key in the component (the event handler does not get called)

Demo project: https://github.com/standbych/radzen-keypress

Expected behavior
It should be possible to add custom event handlers or at least make the behaviour configurable.

Originally created by @standbych on GitHub (Jul 9, 2024). **Describe the bug** It's not possible to use any custom onkeydown handlers anymore, because of the @onkeydown:stopPropagation added for https://github.com/radzenhq/radzen-blazor/pull/1379. **To Reproduce** Steps to reproduce the behavior: 1. Add a RadzenNumberic component 2. Add @onkeydown event handler 3. run and press any key in the component (the event handler does not get called) Demo project: https://github.com/standbych/radzen-keypress **Expected behavior** It should be possible to add custom event handlers or at least make the behaviour configurable.

claunia closed this issue

2026-01-29 17:51:40 +00:00

claunia commented

2026-01-29 17:51:41 +00:00

@enchev commented on GitHub (Jul 9, 2024):

I don't think we should do that. If we allow keydown propagation the internal handling of keyboard events in complex nested components like DataGrid will become nightmare. Key events from the Numeric will clash with keyboard navigation in the DataGrid, etc. Maybe introducing separate KeyDown event for such components will be a better option, still I'm not sure why you need it.

@enchev commented on GitHub (Jul 9, 2024): I don't think we should do that. If we allow keydown propagation the internal handling of keyboard events in complex nested components like DataGrid will become nightmare. Key events from the Numeric will clash with keyboard navigation in the DataGrid, etc. Maybe introducing separate KeyDown event for such components will be a better option, still I'm not sure why you need it.

claunia commented

2026-01-29 17:51:41 +00:00

@standbych commented on GitHub (Jul 9, 2024):

I'd like to have some custom event handling for some keys like "Enter", "Escape" to move forward or reset the value.
The behaviour has worked before, but now I'm stuck with version 4.23.9 - before the stopPropagation was set.
A separate KeyDown event is not that intuitive, but still better than nothing. Wouldn't it be possible to set a CascadingValue in the DataGrid to set the stopPropagation value in the input components? Or a simple parameter which disables the stopPropagation?
The event handling works great for e.g. TextBox, but not Numeric and others anymore...

@standbych commented on GitHub (Jul 9, 2024): I'd like to have some custom event handling for some keys like "Enter", "Escape" to move forward or reset the value. The behaviour has worked before, but now I'm stuck with version 4.23.9 - before the stopPropagation was set. A separate KeyDown event is not that intuitive, but still better than nothing. Wouldn't it be possible to set a CascadingValue in the DataGrid to set the stopPropagation value in the input components? Or a simple parameter which disables the stopPropagation? The event handling works great for e.g. TextBox, but not Numeric and others anymore...

claunia commented

2026-01-29 17:51:41 +00:00

@detchison commented on GitHub (Jan 28, 2025):

I second this.. There has to be a way to trigger events from these fields. Currently In-cell editing, you cannot properly (at all) handle the tab event off of a cell.. and "Change" only detects when there is actually a change to the value, whereas, I need a tab/blur to trigger an event regardless, as even if the value hasn't been changed by the user, I still may need to take an action at that point. Right now, you have to click somewhere else in the grid.. rather than anywhere else to cancel the edit, and even then if the value hasn't changed the event won't fire.

@detchison commented on GitHub (Jan 28, 2025): I second this.. There has to be a way to trigger events from these fields. Currently In-cell editing, you cannot properly (at all) handle the tab event off of a cell.. and "Change" only detects when there is actually a change to the value, whereas, I need a tab/blur to trigger an event regardless, as even if the value hasn't been changed by the user, I still may need to take an action at that point. Right now, you have to click somewhere else in the grid.. rather than anywhere else to cancel the edit, and even then if the value hasn't changed the event won't fire.

claunia commented

2026-01-29 17:51:41 +00:00

@akorchev commented on GitHub (Mar 30, 2025):

Closing as we don't plan to add such a feature. Tab events can be handled via focusin and focusout.

@akorchev commented on GitHub (Mar 30, 2025): Closing as we don't plan to add such a feature. Tab events can be handled via [focusin](https://developer.mozilla.org/en-US/docs/Web/API/Element/focusin_event) and focusout.

claunia referenced this issue

2026-01-29 18:19:50 +00:00

[PR #1291] [MERGED] #1288 NotificationService: Missing IEquatable<T> Implementation #2650

claunia referenced this issue

2026-01-29 18:19:50 +00:00

[PR #1291] #1288 NotificationService: Missing IEquatable<T> Implementation #2653

Sign in to join this conversation.