Hi,

We prefer to have keyboard up/down cursor correspond to navigating input focus up/down a row in the KendoReact Data Grid.

We are already successfully using custom GridColumn Cells to render inputs at all times in tandem with a Grid.onKeyDown handler that finds the next input to set focus.

(for anyone interested this only took a few lines of code to implement a dom navigation heuristic that finds the column index of the nearest TD via onKeyDown event.nativeEvent.target.closest("td") and then finds the corresponding td to that same column index in the next TR up or down, and then hits the first nested native html <input> found to call focus() -  this seems simple and durable to variances in nested components as long as there is a native input to be found, hence the need to render inputs at all times... which does run counter to the approach i saw represented in the KendoReact demos based on setting a particular dataitem's "inEdit" property which wasn't the look we were going for =)

The above cursor navigation is working but before it kicks in, inputs like the DateTimePicker are also taking a cursor up/down to change the date segment that currently has focus - and this doesn't seem to be optional behavior yet?

I believe the fundamental challenge to any dom "wrapper" approach is by the time an outer dom element receives onKeyDown it's too late for event.preventDefault or event.stopPropagation to hide it from the inner input element (the native kendoreact inputs in this case).

Hence the ask here to have an option to ignore that at on the individual KendoReact input components.

With previous KendoReact component builds (e.g. 8.2.0) we successfully proved "patch-package" various subcomponents of DateTimePicker, NumericTextBox and MultiSelect to prevent them from responding to up/down cursor events.

Of course patch-package approach is fragile to upgrades and sure enough recent need to take @progress/kendo-react-dateinputs@9.1.0-develop.6 to get into DateTimePicker formatPlaceholder bug fixes broke previous patches, highlighting need for more resilient fix.

I've attached the latest patch-package files to give precise reference to what keyboard events we're interested in disabling.

I'm assuming this is a feature request and happy to have it reallocated to a support ticket... but wanted to post it in open forums in case community might have alternative suggestions to achieve what we're looking for?

Maybe other approaches to what seems like it could be a general html nested component strategy pattern?

For instance, I'm hesitant to pursue any removeEventListener based approaches for fear of how that might conflict with how i vaguely understand react is continually recreating dom elements upon each render cycle, so i'd be open to encouragement in that direction if anyone has experience to share?

Also wondering if this falls into the realm of "accessibility" and maybe there's already ways to disable accessibility? (as negative as that sounds).