Hello Gary,

Thank you for this clarification. Removing an already declared pane in the DockManager is not currently a supported scenario, but it seems to me like a valid use case.

To completely remove a pane, you must remove it from the declaration (e.g., if you iterate over a collection of objects to declare panes, remove the object from that collection) and then re-render the component. Alternatively, you must exclude it from the state and ensure it is no longer declared.

===

Regarding your questions:

State Structure Changes: It is highly unlikely we will change the state structure, as the preserve state functionality and most of the internal logic of the component relies on it. Any modification would be a major breaking change.

API Enhancements: Since manual state manipulation is difficult, we are considering exposing API methods to exclude panes from the structure.

Data-Driven DockManager: This is not a direct solution to this specific problem, as exposing the root pane(which is what we can basically expose) would still require tree traversal to remove a specific node.

Exposing a configuration or method to remove panes from the current state is a valid feature request. If this meets your requirements, we can log it separately and close this thread.

===

As for whether your current implementation might break in the future: it is unlikely. While I cannot guarantee 0% change, the core logic relies on this structure. We generally state that manual state manipulations are unsupported because an invalid structure (e.g., a tab pane containing a child split pane) will cause exceptions. If your modifications follow the valid DockManager structural rules, the component should function correctly.

Regarding your second question: "Does the safe container approach eliminate the need to traverse the DockManagerState...?"
Essentially, yes. However, if your current implementation is already working as intended, switching approaches may not be necessary.

Please let me know if you need additional information or if you would like to log a feature request for methods to exclude panes after declaration.

Regards,
Yanislav
Progress Telerik

Hello Craig,

You can add new panes inside both floating and non-floating containers, however, to support dynamic insertion, the parent container must persist.

Please review this example: https://blazorrepl.telerik.com/GguRnbYK55cx0zD648.

It uses a DockManagerSplitPane with AllowEmpty="true", which acts as the necessary anchor for adding content panes dynamically. While this differs slightly from inserting panes directly as children of DockManagerPanes, it ensures the structure remains intact. Let me know if this approach meets your requirements.

Regards,
Yanislav
Progress Telerik

Hello Gary,

I will try to answer your questions below:

1. As for the Closeable parameter - by design, a closed pane is not a removed pane. While adding a built-in UI for restoring closed panes is a valid feature request, they currently remain in the state because restoring them (setting Visible="true") forces the DockManager to find their appropriate place in the layout based on their last visible position.

The state becomes "bloated" because the shared implementation continuously adds new pane instances instead of restoring closed ones. You can bind the Visible field (@bind-Visible="paneEntity.Visible") and toggle the value after a pane is closed to restore it. This ensures it renders in the correct location without adding new panes. You can define all panes initially as non-visible and "restore" them to render. This is supported and works dynamically. REPL Example: https://blazorrepl.telerik.com/mKYHQyOs58W2gWNk12

Alternatively, if you require dynamically added panes with unknown content, you can use the safe container approach discussed earlier.

In short to your questions: 

> Using Closeable, is there a way to identify closed panes?

Since you are defining panes from a dataset, you can bind the panes and identify closed panes by filtering for those where `Visible == false`.

> Using Closeable, is there a way to remove a pane from the DockStateManager rather than setting Visible to false?

Currently, the Close button implementation simply raises the `VisibleChanged` event with a value of `false`.

> Is there a way to determine whether the layout stored in DockManagerState differs from the layout defined in the Razor page?

You can compare the initial state (captured when OnStateInit is triggered) with the current state obtained via the GetState method whenever a new pane is added. You can also track layout changes by monitoring the OnStateChanged event.

> If the layout differs from the Razor layout, can we conditionally use a "safe container"; otherwise, use the default layout?

Yes, this is a viable solution. You must ensure that the container where new panes are added remains present and is not destroyed by the DockManager.

I hope this information helps. Let me know if you need further assistance. 

===

Hello Craig, 

Thank you for your feedback and your interest in enhancing the DockManager component.

Could you please elaborate on the specific use case? I want to ensure I fully understand the purpose of the DynamicContentPanes configuration and its expected behavior. Since the DockManager utilizes a parent-child structure rather than flat collections that can be concatenated, it is currently unclear how these dynamic panes would render or interact with the existing hierarchy.

I am also interested in the requirement for dynamic parameters and how you envision them functioning. To provide the best possible solution, it would be helpful to understand your ultimate end goal rather than the specific configuration needs.

Side note: This appears to differ from the initial requirement in this thread. If so, to keep our communication organized, could you please open a separate thread to describe your goal and exact requirements?

Thank you for the additional details in advance. 

Regards,
Yanislav
Progress Telerik

Hi Gary,

Thank you for preparing the example and the video, I was able to reproduce the behavior. 

I will try to address the issues separately:

State Synchronization and Pane Persistence

The DockManager definition and its state are not synced. Once a user changes the layout, the definition and the state of the panes differ.

In your project, a split pane is rendered for each column. These are defined with AllowEmpty="false". This tells the DockManager to destroy any pane/splitter/column that has no children. By design, all parent panes (tab groups and splitter panes) are destroyed when empty.

You can keep these panes by setting AllowEmpty="true". This ensures the pane remains so new records can be rendered inside it. Otherwise, once a parent pane is left without children, the DockManager ignores it. This is the reason why sometimes the panes are not included even though they are part of the dataset.

Managing Empty Columns

If your goal is to avoid empty panes while keeping the AllowEmpty="false" configuration, you have two options:

• Remove the column: Use the OnUndock event. Check the undocked content pane ID and the child count of the column (its parent). If the count is 0, remove the column from the dataset.
• Hide the column: Use the same condition (children == 0) and set Visible="false".

This allows you to keep the column structure so new content panes are inserted evenly. Here is an example demonstrating this approach: https://blazorrepl.telerik.com/GAaHvWvI20ym4GK113

Potential Enhancements

Handling this manually requires tracking onDock and onUndock to count children for each column. I see an opportunity to improve this by exposing an event that tracks when a parent pane is left without children. This would allow you to hide and show it automatically. Let me know if you are interested in this feature, and we can log it for implementation.

Data-Driven DockManager

A data-driven approach will not simplify the process of adding new panes because the DockManager utilizes a multiple-tree structure. In this architecture, floating panes act as independent "mini-dockmanager" trees managed by the component.

Even if root panes are exposed, adding dynamic panes still requires you to access the current state and traverse the structure to identify the correct parent node.

If your primary goal is to add new panes into the layout, a more efficient method is to define an empty splitter pane and iterate your data within it. This acts as a "safe container" for dynamic children.

Please let me know if you would like me to prepare an example of this configuration.

===

Resize evenly 

Please correct me if I am mistaken, but the resize button in the provided example appears to function identically in both the workaround and default modes.

    public async Task ResizeEvenly()
    {
        await InvokeAsync(async () =>
        {
            Console.WriteLine("Resize Evenly");
            DockManagerKey = Guid.NewGuid().ToString();
            this.StateHasChanged();
        });
        TelerikNotificationRef?.Show(new NotificationModel() { Icon = Telerik.SvgIcons.SvgIcon.Check, CloseAfter = NotificationTimeout, ThemeColor = ThemeConstants.Notification.ThemeColor.Success, Text = $"Resized Evenly with {Columns} Columns." });
    }

I am not entirely sure of the exact purpose of this method, as it changes the @key directive value of the DockManager component. By default, if no Size parameter is passed to a pane, the splitter children are sized evenly. Changing the @key value triggers a complete re-render of the component, which resets all panes to their initial defined positions and calculates their size.

Sizing all content panes evenly can currently be achieved without re-rendering the entire component. However, this requires traversing the state, calculating the sibling count for each content pane, and manually setting its Size parameter. Since such implementation is complex, exposing a dedicated method to resize all panes evenly can be logged as a separate feature request.

However, I would like to ask you to elaborate more on your ultimate goal for this so we can discuss the best approach.

Please review these suggestions and let me know if I have missed any specific requirements.

Regards,
Yanislav
Progress Telerik

Hello Gary,

Thank you for attaching a solution and a video. We are in the process of reviewing and validating the requirements and will get back to you shortly. 

Regards,
Ivan Danchev
Progress Telerik

Hello Gary,

Thank you for the comprehensive explanation of the problem you are facing with the current DockManager capabilities and the functionality you've requested.

I've made the feature request public on our Feedback Portal, which would allow other members of the community to vote for it. 

Regards,
Ivan Danchev
Progress Telerik