We are using the blazor chat component with Microsoft.Extensions.AI and IChatClient. Currently during a long response stream the chat repeatedly scrolls to the bottom automatically as the response updates. When I use use my mouse wheel to scroll to the top it immediately auto scrolls me back to the bottom.

A user needs to be able scroll to the top as the response is streaming in. If the user manually scrolls the auto scrolling should stop. Any subsequent messages sent in the same chat session should resume auto scroll. This is the behavior seen in most AI chat interfaces like chatGPT and is what most users expect. 

For more info and a video refer to support ticket: 1712888

Thanks, Justin.

Hello,

Currently the Telerik diagram component looks very promising but lacks the option to better control what's shown inside each DiagramShape (Block, node). Wouldn't it be possible to allow a Template renderfragment inside of these shapes so we can fully control what's shown? This way we can build more complex diagrams with images, text, buttons inside.

Goal

Our application needs to allow end users to dynamically customize the Telerik Blazor DockManager at runtime by:

• Adding new panels
• Removing existing panels
• Rearranging and resizing panels

These changes should be fully user-driven and persisted so that:

• The layout is restored when the user returns
• The layout is consistent across browsers and devices

In short, we want the DockManager to behave as a customizable dashboard whose state can be reliably stored and reloaded from our database.

Problem

The current Telerik Blazor DockManager implementation requires panels to be declared in Razor markup (markup driven) and managed through an external data source.

This creates several challenges:

• The component state (DockState) is tightly coupled to the initial panel definitions.
• Dynamically adding or removing panels from the data source conflicts with the internal DockState.
• To synchronize changes, we must manually manipulate the DockState object using custom code.
• This manipulation relies on internal behavior that is not formally supported and may break in future Telerik releases.

As a result, implementing a truly dynamic and persistent DockManager layout requires complex workarounds that are fragile and difficult to maintain.

Feature Request

We propose enhancing the DockManager with first-class support for dynamic panel synchronization by introducing:

Two coordinated parameters:

• Data – the collection of panels
• DockState – the persisted layout information

Expected behavior:

• If the Data collection contains a panel that is not present in the DockState, the component should automatically:
  • Add the new panel to the layout
  • Place it at the end of the current structure (bottom or right, depending on layout)
  • Update the DockState accordingly
• If the DockState contains a panel that is no longer present in the Data collection, the component should automatically:
  • Remove that panel from the layout
  • Update the DockState accordingly

This would allow developers to treat the DockManager as a true data-driven component, similar to other Telerik Blazor controls, without needing to manually modify internal state structures.

Currently, on mobile devices (where is no hover), to open the child menu you need to click/tap the parent and the only way close it afterwards is if you click away. This is not very convenient for mobile usage. I want to be able to close the child menu on click/tap of the parent as well.

The ability to choose which options to appear in the ContextMenu.

=====

TELERIK EDIT: In the meantime, here is how to hide context menu items with CSS:

    /* Hide the Rename item in the FileManager context menu */
    .k-context-menu:has(.k-svg-i-download) .k-menu-item:nth-of-type(1) {
        display: none;
    }

    /* Hide the Delete item in the FileManager context menu */
    .k-context-menu:has(.k-svg-i-download) .k-menu-item:nth-of-type(3) {
        display: none;
    }

Here is a complete example: https://blazorrepl.telerik.com/cpPkuBEq408A36p010

Hi,

The ask is for a feature request to take the already wonderfully done globally applied filter features down to a per column basis without the overhead and burden of resorting to the custom FilterMenuTemplate approach.

The current way of doing business creates much overhead in code particularly when several columns are involved.

Something like:

<TelerikGrid Data="@MyData"
FilterMode="@GridFilterMode.PerColumn"

<GridColumns>
<GridColumn Field="MyField01" FilterMode="@GridFilterColumnMode.FilterRow" />

<GridColumn Field="MyField02" FilterMode="@GridFilterColumnMode.FilterMenu" />

<GridColumn Field="MyField03" Filterable="false"/>

etc..

</GridColumns>

</TelerikGrid>

Thanks!

Ron

Hello,

I need to be able to set the colors of x-axis category labels conditionally. My current use case for this is that I'm displaying dates and need weekends and holidays to be their own colors. As far as I'm aware this cannot be accomplished in any way currently:

• ChartCategoryAxisLabels Color parameter cannot be conditional and applies to all labels
• ChartCategoryAxisLabels Template parameter must return plain text and cannot render styling or HTML
• The labels are drawn via canvas and therefore cannot be styled externally

The two solutions I could suggest are as follows:

1. Make the ChartCategoryAxisLabels Color parameter able to be Kendo UI parsed like the Template Parameter
2. In addition to the ChartCategoryAxis Categories parameter, support providing categories as render fragment children, with each having its own Color parameter

Thanks,
Robert

If LoadGroupsOnDemand="false", I am able to programmatically expand the groups through the state. However, this is not possible when loading group data on demand.

Please allow programmatically expanding the groups when LoadGroupsOnDemand="true". This should go together with an event (OnStateChanged?) that will fire when LOD groups are expanded or collapsed.

Currently, a TextField value of empty string will produce a blank item in the dropdown.

On the other hand, a null TextField value will produce the fully qualified class name.

Here are possible workarounds: https://blazorrepl.telerik.com/myOlFpFb1465jW8E07

Draft feature request (copy/paste)

Title: Add per-column value converters (WPF-style) to Telerik Blazor Grid columns

Product: UI for Blazor → Grid
Type: Feature Request

Description:
In Telerik UI for WPF, grid column definitions can reference a converter by name (e.g., IValueConverter) to transform values for display without writing a custom cell template for each column.

In Telerik UI for Blazor Grid, templates are currently the primary way to change how values render in a column (which works, but becomes repetitive across many columns/grids).

Request:
Add a column-level conversion API that allows specifying a converter/formatter function for display (and optionally editing). Example concepts:

• Converter="nameof(MyConverters.StatusToText)"

• or DisplayConverter="(item) => …" / ValueFormatter="Func<TItem, object, string>"

• optionally ConvertBack-like support for editing scenarios (or separate EditConverter)

Why this is needed:

• Reduces repeated <Template> markup for simple formatting/transformations

• Centralizes formatting/conversion logic in reusable code

• Improves maintainability and consistency across grids

• Eases migration for teams coming from Telerik WPF where converters are a common pattern

Use cases:

• Enum/int → user-friendly text

• Boolean → “Yes/No”, icons, badges

• Null/empty → placeholder text

• Code → display name (via lookup)

• Domain-specific formatting shared across many grids

Workarounds today:

• Column <Template> or computed properties (both valid, but not as concise/reusable for large grids)

• Extracting RenderFragments can reduce repetition, but still requires templating infrastructure for what is logically a simple conversion step

Expected behavior:

• Converter applies consistently anywhere the column renders (cell, export if applicable, etc.)

• Works with sorting/filtering in a predictable way (ideally sorting/filtering still uses raw field value unless explicitly configured)