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