Hello,

Please add a feature to highlight areas of a PDF on specific pages.  This feature is available in a different library - React PDF Viewer library - but that is apparently no longer supported, and has security vulnerabilities:

https://react-pdf-viewer.dev/examples/render-the-highlight-areas/

This is a critical feature for an application we are building.  Thank you for any assistance.

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).

When your window control closes, focus returns to the element that invoked the window unless it is very unlikely users need to immediately reinvoke the window.

We use your window control as a popup search dialog. Our customers search for their data there, close the popup and then return to a dialog with lots of input fields.
The user had previously focused on one of these input fields and would like to have the focus back in this input field after closing the popup.
Which has worked wonderfully up to and including your version 8.0.0.

Unfortunately, this no longer works since version 8.1.0 and instead of the input field, only the button that previously opened the popup is focused. This change from the changelog seems to be responsible for this: "window: update focus management and kb navigation to match the ARIA spec".
It seems that your change uses a setTimeout internally, which keeps taking the focus away from our input field.

You can reproduce this behavior in a demo application. The first application is based on version 8.3.0 and you can reproduce the problem there by pressing the button and closing the opened popup. The focus that was previously in the input field is then on the button. Here: https://stackblitz.com/edit/react-xdpeqc-nycw86?file=app%2Fapp.tsx,package.json
In the second application based on version 8.0.0, you can see that the same process sets the focus directly back to the input field. Here: https://stackblitz.com/edit/react-xdpeqc-yab7m8?file=package.json,app%2Fapp.tsx

Nowhere in the ARIA specification here does it say that you should use a setTimeout to steal the user's focus again at a later time in order to set it on the button that opened the popup. On the contrary, point 2.1 describes exactly what we need:

You already had this feature in version 8.0.0 and could offer it again as a property with very little implementation effort. Please consider to add this old behaviour as a Window Prop again.

If the zoom property is set on the body element for a preset zoom your window control does not seem to correctly take this zoom into account for the position and width/height of the window. You can easily recreate this in the following example application: https://stackblitz.com/edit/react-qmwfbf-fzmj98?file=app%2Fapp.tsx,index.html

Simply open the window using the button and then maximize the window in the title bar at the top. You can see that the width/height calculation is much too large and is not correctly maximized to the available space. You can also see this in the attached video.

A similar problem has already been reported here for popups https://github.com/telerik/kendo-react/issues/2320 and there is also a solution for this using the scale property in the PopupProps here:

<PopupPropsContext.Provider
      value={(props) => ({
        ...props,
        scale: 1.25,
      })}
    >

Please add exactly the same scale property for the WindowProps. 

In the jQuery version of the scheduler, there is an option to disable snapping and to allow free move of the events.

How to achieve this behaviour in the React version?

Our client requirement is they need to modify any dates using datepicker.

For example

if 11/11/2024 need to change 11/12/2024

just a single one digit change is not permitted we need to type 12 which is 2 digit change that means complete day

same happens for month and year as well

We found Carbon-date-picker provides similar functionality which solves our requirement where we can modify each and every digit of datepicker element

I'm in need of the format Year/WeekOfTheYear/DayOfTheWeek for the date range picker. Ex. 2024/44/3, meaning the year 2024 week 44 day Wednesday. 

This is not supported currently, please vote for it's implementation if format support has been an issue for you too.

Hello,

i am new to React and Kendo React UI.

I am reading the documentation for Gantt, and if i understand it correctly i can customize header column (headerCell?), but I dont know how. Is there any examle ?

I wound like to customize the column with dates.

Thank you, Matjaz Reberc

Dear Sir/Madam,

We are piloting our application and repeatedly get the same feedback from our users: they find entering information in the date and time inputs annoying.

The reason for this is that they have to enter a date (say 1 december 2024) by entering:

• Day (1)
• Press /
• Month (12)
• Press /
• Year (2023)

Instead, they would like to enter a date in one go, say

• "01122023" should resolve to 1 december 2023.

• "0112" should resolve to 1 december 2024, because year is missing and we can then assume that we use the current year.

Likewise, they would enter times like "1005" for "10:05". Now they have to enter ":" to go to the minutes field.

We would like to respond to their feedback, but don't know to implement this. Is this something that Kendo supports? If not, we are willing to pay to give this feature request priority. Could you help us out?

Regards,

Peter