Add a per-file concurrency option so the Upload component can send multiple chunks of one file simultaneously. The currently available concurrent property only controls whether files upload simultaneously, but does not give the ability to control the concurrency of the chunks in an individual file.

The typing for Telerik events in Angular that I have seen so far is generally quite mixed in quality. There is heavy use of EventEmitter<any> for some commonly used components, which is a code smell in TypeScript.

It makes it considerably more difficult/risky to develop using these events, as you don't quite know what to expect until you try running it a few times and/or playing around with it on the website sandbox. Furthermore, the sandbox has its own issues too, such as not always making it clear if a value is null/undefined vs an empty string (which does make a difference for how you handle it), so I typically have to make a dummy component and debug it myself just to find out.

See for instance:

• Text boxes
• Numeric text box
• Combo boxes
• Multiselect

Others have a mix of typed and un-typed

• Drawer layout
• Multiview Calendar

A component that does this well by contrast is the Map one, where the events are all strongly typed, making them much easier and safer to use.

In certain cases (e.g. Comboboxes), where a value change emits the selected object/string, or "undefined" (at least as far as I can tell), could it not use generic typing to infer the type based on the type of the provided data, and default to "any" otherwise?

For focus/blur events, at least the switch component provides typing that lets me know it refers to the original DOM event (though it still has "any" on the valueChange - which seems unusual as I'd intuitively expect it to be a boolean).

Even if it is truly impossible to get typing for certain events, there should at least be clearer documentation on the API reference of what you should typically expect to get/where the event comes from.

Component libraries should not require you to guess or figure out what to expect for exported events. Please can you make this a priority in new releases.

Hi,

Dear Telerik Support Team,

would it be possible to add Constrained Mode support for the TreeList, given that it already exists for the Grid?

The Grid's resizable input accepts "boolean | ResizeMode", so resizable="constrained" keeps the overall table width fixed while resizing. The TreeList's resizable input is boolean only, and we could not find an equivalent option.

In our application, Grid and TreeList are wrapped by two components that are supposed to look and behave identically. Without constrained mode, shrinking a TreeList column leaves empty space to the right of the table whenever no horizontal scroll bar is present; the table stops filling the available width, whereas a grid next to it still does.

We are currently working around this issue by adding an additional spacer column, but that relies on internal DOM details of the TreeList and is likely to break with future updates. Native support would allow us to remove the workaround.

Tested with version 23.4.0; the public API docs suggest this is still the case in the latest release.

Thanks a lot in advance!

Add built-in support for importing and preserving native Excel tables in the Spreadsheet component.

When an XLSX file contains a table created through Excel’s Insert > Table feature, the Spreadsheet should parse and retain the table definition, including its metadata, style, structured references, automatic expansion, and filter buttons.

When the workbook is exported, the corresponding native Excel table parts should be written back to the XLSX file so the table remains a functional Excel Table.

Hi,

It will be a nice addition to the component if a resizeStart and resizeEnd events are introduced to the component. These events will fire once and will be useful for API calls or other operations that need to be called once as the current resize event fires multiple times.

Thank you for your consideration.

As the FilterInputWrapperComponents set currentOperator(value: string) uses a hard coded list of operator values (isnull isempty isnotnull isnotemty), it is impossible to create a custom FilterOperator that has no search string - so we can't have isnullorempty isnotnullorempty (or isblank/isnotblank).

Please introduce a requiresSearchValue on the FilterOperatorBase class and make sure FilterInputWrapperComponents does decisions based on that.

Please introduce a isnullorempty/isnotnullorempty filter operator (for strings).

Additional context/sample usage:

 <kendo-grid-column title="Employee / Prospect" field="Name" width="160">
            <ng-template kendoGridCellTemplate let-field let-value let-dataItem>
                <span *ngIf="dataItem.IsProspect" class="pull-left">{{dataItem.Name}}
                    <p class="prospect-indicator pull-right" data-letters="P"></p>
                </span>
                <span *ngIf="!dataItem.IsProspect">{{dataItem.Name}}</span>
            </ng-template>
            <ng-template kendoGridHeaderTemplate let-column>
                <span title={{column.title}}>{{column.title}}</span>
            </ng-template>
            <ng-template kendoGridFilterMenuTemplate let-filter let-column="column" let-filterService="filterService">
                <kendo-grid-string-filter-menu
                    [column]="column"
                    [filter]="filter"
                    [filterService]="filterService">
                    <kendo-filter-eq-operator></kendo-filter-eq-operator>
                    <kendo-filter-neq-operator></kendo-filter-neq-operator>
                    <kendo-filter-contains-operator></kendo-filter-contains-operator>
                    <kendo-filter-not-contains-operator></kendo-filter-not-contains-operator>
                    <kendo-filter-startswith-operator></kendo-filter-startswith-operator>
                    <kendo-filter-endswith-operator></kendo-filter-endswith-operator>
                    <kendo-filter-isblank-operator></kendo-filter-isblank-operator>
                    <kendo-filter-isnotblank-operator></kendo-filter-isnotblank-operator>
                    <kendo-filter-isempty-operator text="xIs blank"></kendo-filter-isempty-operator>
                    <kendo-filter-isnotempty-operator text="xIs not blank"></kendo-filter-isnotempty-operator>
                </kendo-grid-string-filter-menu>
            </ng-template>
        </kendo-grid-column>

Hi,

 The tree view enables us to drag and drop one item at a time. we have a scenario where i want to drag and drop multiple items. tree view also enables multiple selection of items but not supporting drag and drop of multiple items. Could you please provide some solution to dag and drop multiple items

Thanks& regards,

Ramesh M

Hi,

When a task is collapsed, how can I show the child tasks overlapped ontop of each other, rather than just a blank skinny line? When collapsed, I'd like to see all my tasks (and their templates/bars/titles) side-by-side or overlapping (if their startDates and endDates overlap)?

thanks

Currently, the row pinning functionality of the Grid duplicates the pinned rows in both the pinned section and the normal row section.

Provide a way to avoid this duplication and have the pinned rows displayed only in the pinned section.

`@progress/kendo-intl` incorrectly formats timezone offsets whose minute component is non-zero.

For example, a JavaScript `Date` with the historical Warsaw offset `UTC+01:24` is formatted as `+01:04` instead of `+01:24`.

This affects all tested `Z`, `X`, and `x` timezone format variants.

Environment

- `@progress/kendo-angular-intl`: `24.2.0`
- `@progress/kendo-intl`: `3.2.1`

- Browser/Node timezone: `Europe/Warsaw`
- Operating system: Windows
- Format: `yyyy-MM-ddTHH:mm:ssZZZZZ`

The same formatting implementation appears in `@progress/kendo-intl` versions `3.1.2` and `3.2.1`.

Reproduction

const { formatDate } = require('@progress/kendo-intl');

process.env.TZ = 'Europe/Warsaw';

const date = new Date(1900, 0, 1, 16, 0, 0);

console.log(date.toString());
console.log(date.getTimezoneOffset());
console.log(formatDate(date, 'yyyy-MM-ddTHH:mm:ssZZZZZ'));

Actual Result

Mon Jan 01 1900 16:00:00 GMT+0124
-84
1900-01-01T16:00:00+01:04

Expected Result

1900-01-01T16:00:00+01:24

Date#getTimezoneOffset() returns -84, meaning the local timezone is 84 minutes ahead of UTC:

84 minutes = 1 hour 24 minutes

Other Examples

The issue is not limited to positive offsets:

UTC is also formatted differently depending on the token, but that behavior may be intentional:

Tested Format Specifiers

All applicable format variants use the same incorrect minute calculation:

Z      -> +0104
ZZ     -> +0104
ZZZ    -> +0104
ZZZZ   -> GMT+01:04
ZZZZZ  -> +01:04

X      -> +0104
XX     -> +0104
XXX    -> +01:04
XXXX   -> +0104
XXXXX  -> +01:04

x      -> +0104
xxx    -> +01:04
xxxxx  -> +01:04

Changing from ZZZZZ to XXXXX or XXX therefore does not resolve the problem.

Suspected Root Cause

The current formatter appears to perform approximately this calculation:

const offset = date.getTimezoneOffset() / 60;
const hoursMinutes = Math.abs(offset).toString().split('.');
const minutes = hoursMinutes[1] || 0;

For an 84-minute offset:

84 / 60 = 1.4

The decimal portion "4" is then treated as four minutes and padded to "04".

However, the fractional part represents a fraction of an hour:

0.4 hours * 60 = 24 minutes

Likewise, for 210 minutes:

210 / 60 = 3.5

The formatter produces 03:05, although 0.5 hours is 30 minutes.

Suggested Fix

Timezone offsets should remain integer minute values throughout formatting:

function formatTimeZone(date, info, options) {
    const totalMinutes = date.getTimezoneOffset();
    const absoluteMinutes = Math.abs(totalMinutes);
    const hours = Math.floor(absoluteMinutes / 60);
    const minutes = absoluteMinutes % 60;
    const sign = totalMinutes <= 0 ? '+' : '-';

    // Continue applying shortHours, separator, optionalMinutes,
    // localizedName and zZeroOffset options using hours and minutes.
}

The important calculations are:

const hours = Math.floor(Math.abs(offsetMinutes) / 60);
const minutes = Math.abs(offsetMinutes) % 60;

Converting the offset to a decimal hour and splitting its string representation is not reliable.

Suggested Regression Tests

it('formats a positive timezone offset with minutes', () => {
    const date = new Date(2024, 5, 25, 12, 7, 5);
    vi.spyOn(date, 'getTimezoneOffset').mockReturnValue(-84);

    expect(formatDate(date, 'yyyy-MM-ddTHH:mm:ssZZZZZ'))
        .toBe('2024-06-25T12:07:05+01:24');
});

it('formats a negative timezone offset with minutes', () => {
    const date = new Date(2024, 5, 25, 12, 7, 5);
    vi.spyOn(date, 'getTimezoneOffset').mockReturnValue(210);

    expect(formatDate(date, 'yyyy-MM-ddTHH:mm:ssZZZZZ'))
        .toBe('2024-06-25T12:07:05-03:30');
});

Other useful cases include:

-345 -> +05:45
-330 -> +05:30
210 -> -03:30
0 -> Z or +00:00, depending on the selected token

Impact

This can corrupt serialized date-time values when they are passed to systems that honor the emitted offset, including .NET DateTimeOffset.

Example:

Intended: 1900-01-01T16:00:00+01:24
Emitted:  1900-01-01T16:00:00+01:04

These values represent instants 20 minutes apart.

The issue affects:

• Historical dates from regions that previously used local mean time.
• Current timezones with half-hour or quarter-hour offsets.
• Any test or custom Date implementation returning a non-whole-hour offset.

Examples of modern fractional offsets include UTC+05:30, UTC+05:45, UTC+09:30, and UTC-03:30.

Additional Context

We initially encountered this with Europe/Warsaw and 1900-01-01. The JavaScript runtime correctly reports Warsaw's historical offset as UTC+01:24. The incorrect UTC+01:04 value is introduced only during Kendo formatting.

We have implemented a temporary application-level workaround that formats the date portion with Kendo and calculates the timezone offset directly from integer minutes.

StackBlitz

Hello,

I have prepared an example, here's how you reproduce the bug (https://stackblitz.com/edit/angular-2nwrn7db?file=src%2Fapp%2Fapp.component.ts):

1. Move the Product Name column between the Category and Unit Price columns
2. Save the Grid state using the Save State button
3. Reload the page
4. Restore the saved state using the Load State button
5. The multi-column Test (k-grid0-col4) has the wrong OrderIndex (0 instead of 4)

Best regards,

Igor

Currently, there is no public API to customize the visible month window. The built-in header buttons move the months window by a two-month span.

Provide a way in the MultiViewCalendar to programmatically shift the displayed months by one month backward or forward. For example:

1. Calendar currently shows June and July
2. User clicks a Previous button - calendar should show May and June
3. Or, user clicks a Next button - calendar should show July and August