Forum

I would like to restrict grouping of the CExtResizable bars into tab container only to bars within the same circle. Say if there is a bar (A) docked at circle 1 (as I understand from help file it should start from 1) and two bars (B and C) docked at circle 2. I would like to disable grouping of B and C with A but still be able to group B and C together. In my particular case A has no gripper so it can’t be dragged to another bar.

In 2.3X there was a different docking behaviour for "Like 2003" and "Like 2005" modes. "Like 2005" was doing exactly what I needed. It was restricting docking to the circle 2. "Like 2003" allowed to dock anywhere and thus grouping with bar from circle 1. In 2.40 this has changed and both modes behave the same - i.e. just like old "Like 2003".

Another way which will work for me as well is to allow disable groupping of internally docked bars together with externaly docked ( with DockControlBarInnerOuter( AFX_IDW_DOCKBAR_LEFT, false, this, true ); ). Is it possible?

Thank you in advance for your help.

This can be done by overriding the following internal method in your CExtControlBar-derived class:

protected:
    virtual bool _CanDockToTabbedContainers(
        CExtControlBar * pDestBar
        ) const;

CExtDynControlBar * pDynBar =
    DYNAMIC_DOWNCAST(
        CExtDynControlBar,
        pDestBar
        );
    if( pDynBar == NULL )
        return . . .
    ASSERT_VALID( pDynBar ); 
    ASSERT_VALID( pDynBar->m_pWndDynDocker );
CWnd * pWnd = pDynBar->m_pWndDynDocker->GetWindow( GW_CHILD );
    while( pWnd != NULL )
    {
        ASSERT_VALID( pWnd );
        CExtControlBar * pOtherBarInGroup =
            STATIC_DOWNCAST(
                 CExtControlBar,
                pWnd
                );
        // analyze whether the pOtherBarInGroup
        // can be docked within this bar into the
        // same tabbed group
        . . .
        pWnd = pWnd->GetWindow( GW_HWNDNEXT );
    }

ON_REGISTERED_MESSAGE(
    CExtControlBar::g_nMsgCreateTabbedBar,
    OnCreateTabbedBar
    )

LRESULT CMainFrame::CreateTabbedBar( WPARAM wParam, LPARAM lParam )
{
CExtDynTabControlBar ** ppTabbedBar =
            reinterpret_cast
                < CExtDynTabControlBar ** >
                (wParam);
    (*ppTabbedBar) =
        new C_YOUR_DynTabControlBar;
    return 0;
}

Thanks for reply. It looks like this way it is possible to disable undesired docking operation, but it is not very elegant. In "Like 2005" docking mode there are still arrows and "tabs" image offering docking to the bar A (from above example). But when dragged pane is dropped in its just remains floating.

I’ll try to explain the reason for docking algorithm restriction. Document view has two areas: one is a tree to select document items and another is item view  (think of Explorer window). There are several different types of items each has its own view with differerent dockable bars (panes). Selecting different items in the tree changes item view. Users can rearrange panes in each item view as they like. Ideally panes should be restricted to the item view area.

Since bars need frame window as parrent all panes (from all item views) and tree are created at the moment as bars in ChildView. Selecting some item in the tree saves current state of panes, hides them all and restores state of panes for newly selected view.

If there is a way to have panes dockable in a regular window - it will solve all problems. Then selection tree will be a resizable bar in ChildFrame and each view will have its own set of panes and they automatically will be bound to it. Actually this will be an ideal solution as it will allow much better switching between views. Is it possible to modify window derived from regular CWnd to support docking of CExtResizableBars?

If you try to enumerate all possible relative positions of three or more resizable control bars, you will certainly come to conclusion that there is no reason to restrict their docking algorithm. The idea of a resizable control bar as it is implemented in Visual Studio .NET implies a window that is not restricted by its size and position. If you take a look at the class tree in Visual Studio 2005, you will see that it contains neither class methods nor property members. The methods and properties are placed in the separate list box at the bottom of the class tree. The class tree and members list box are inserted into a splitter-like container window. So, we can assume the class members list box is a preview window for the currently selected item in the class tree. This idea is not new. The properties window uses the same splitter-like container for displaying property description text at the bottom of the property grid control. In both cases the top window contains are not overloaded with information because the details are displayed in the bottom "preview" window. These real life samples demonstrate a good preview/details UI design. Of course, it makes sense when the amount of preview information is not large. If the preview window requires extensive horizontal/vertical scrolling because of lots of information to display, you can use the MDI interface and open a tree item preview as an MDI child window.

As for your last question, we do not see principal differences between frame windows, dialog boxes, generic CWnd windows, common controls and so on. Yes, control bars can be re-dockable only inside CFrameWnd because it is a container window which supports re-docking for control bars, hiding when an OLE object is in-place active and much more. If you need a dialog, then you can use it as a child view and in this case the design of the main frame window and child dialog windows is not much more complicated than a single dialog box as the main window.

We would appreciate if you send us some screenshots so that we can continue this discussion in details.