Forum

I have a CExtControlBar bar that i want to resize from the code when it is floating.
I could not find any function to resize in the CExtControlBar, and the CWnd’s MoveWindow had no effect when called.

Please explain how this task can be done.

Here are some additional details in addition to what Chris wrote. You can use the following code:

CSize sz( nWidth, nHeight );
m_wndResizableBar.SetInitDesiredSizeFloating( sz );

CFrameWnd * pFrame = m_wndResizableBar.GetParentFrame();
ASSERT( pFrame );
if( pFrame->IsKindOf( RUNTIME_CLASS( CMiniDockFrameWnd ) ) )
{
	pFrame->RecalcLayout();
	pFrame->SendMessage( WM_NCPAINT ); 
}

Please note that in the code above the layout of control bar’s parent floating mini frame window is forcibly recomputed.

You can also download this small sample that demonstrates how to change the size and position of a floating control bar.

In order to change the size of a docked control bar, you should additionally invoke the CControlBar::CalcDynamicLayout() API and specify LM_COMMIT in its parameter. For instance, the following code specifies the height of 50 pixels for a horizontally docked control bar:

INT nDesired = 50;
pMainFrame->m_wndBarTop.SetInitDesiredSizeHorizontal( CSize( 32767, nDesired ) );
pMainFrame->m_wndBarTop.CalcDynamicLayout( nDesired, LM_HORZDOCK|LM_COMMIT );
pMainFrame->RecalcLayout();

Another question - How do i get the current size and position of the bar?
I would like to change only one parameter - the height, so i need to know the current location and width.

Thanks.

OK - I figured this one out myself:
The position is position of the GetParentFrame() of the CExtControlBar
The size is the size of the CExtControlBar and to it I add my delta:


CFrameWnd* pFrame = pBar->GetParentFrame();

CRect rc;
pFrame->GetWindowRect(rc);
CRect rcBar;
pBar->GetWindowRect(rcBar);

pBar->SetInitDesiredPosFloating(CPoint(rc.left,rc.top));
pBar->SetInitDesiredSizeFloating(CSize(rcBar.Width(),rcBar.Height()+nDelta));
pBar->FloatControlBar(CPoint(rc.left,rc.top));

pFrame->RecalcLayout();
pFrame->SendMessage( WM_NCPAINT );


Thanks for that sample.

In the same context - a while a go i asked for a way to limit the size of a floating bar to certain size (so it won’t get too small), and never got a full answer - Maybe you can re-check this problem?

Thanks.

You need to prevent any mouse actions with regard to the control bar if these actions are based on clicks on the non client area where resizing is performed. So add the WindowProc() virtual method like as follows:

virtual LRESULT CYourControlBar::WindowProc( UINT message, WPARAM wParam, LPARAM lParam )
{
    if( message == WM_NCHITTEST )
    {
        LRESULT lResult = CExtControlBar::WindowProc( message, wParam, lParam );
        switch( lResult )
        {
        case HTBOTTOM: 
        case HTBOTTOMLEFT: 
        case HTBOTTOMRIGHT:
        case HTTOP:
        case HTTOPLEFT:
        case HTTOPRIGHT:
            return HTCLIENT:
        }
    }
    return CExtControlBar::WindowProc( message, wParam, lParam );
}

In addition please override the following two methods of CExtControlBar:

    virtual void _RowResizingStart();
    virtual void _RowRecalcingStart();

That should be enough to prevent the control bar from being resized. Please note this will work only if your control bar is a single floating bar and not docked with other bars.

Thanks, but it is not complete unless it can handle the cases of tabbed or side-by-side or docked bars.

How to solve this problem?

To give you the complete solution (all cases), we need some time. This feature is not supported in Prof-UIS at the moment and any off-hand advice would be incomplete because this relates to core code of control bars.

Dead Support,

I undestand that it is hard for you to implemenet this at the moment, and hope that you’ll find the time in the near future to implement this feature.

However, there is one problem that derive from this probelm into normal bars:
When two bars are tabbed together or docked side-by-side, they parent changes to the docked or tabbed parent. This prevent the progrematically resizing (at the momemnt...)
When one of the tabbed bars is closed, and only one of the two bars is staying open, still you keep for that one bar the same parent. It seems as this is a normal bar that can be resized, but it isn’t because it was once tabbed.
I think that this problem should be solved ASAP, the tab looks as a normal bar, but it does not behave normal...
Prof-UIS should know that this is the last bar in a tabbed array of bars, and roll bar to the normal parent.

Please try to incorprate this change for next version.

Thanks in advance,
Ron

OK,

Please let me know when to expect this feature to be incorporated into Prof-UIS.
At the same time, i would like to remind you the problem of destroying a docked control bar (KillBar) that also is not supported with docked/side-by-side and tabbed bars.

I would really apreciate a prompt solution to both problems, as we really need these features ASAP.

Thanks,
Ron.

Dear Support,

I am trying to run over all controls in a dialog, but i would like to leave the CExtWSGripper untouched.
I tried using IsKindOf(RUNTIME_CLASS(CExtWSGripper)), without success.

I looked into the declaration of this class, and it is missing a DECLARE_DYNCREATE macro, and that’s why i cannot get the run-time class type of it.

From the MSDN help:

"RUNTIME_CLASS returns a pointer to a CRuntimeClass structure for the class specified by class_name. Only CObject-derived classes declared with DECLARE_DYNAMIC, DECLARE_DYNCREATE, or DECLARE_SERIAL will return pointers to a CRuntimeClass structure."

Please fix this problem ASAP.

Thanks,
Ron.

Dear Support,

I have a dialog that contains several controls.
I have a button in the control that when press hides/shows some of the dialog’s control (acts like a collapse/un-collapse button):
* The button hides some of the dialog’s content, and moves the rest of the controls up.
* The next press, it shows back all the hidden controls, and moves the rest of the controls down.

When doing it using Prof-UIS, using CExtResizableDialog, and setting the dialog’s attributes accordingly (clipping etc.) I see ’leftovers’ after I move the controls (I move them using ::SetWindowPos or ::DeferWindowPos - same result), and the the dialog only re-paints itself correctly when I ’force’ it to redraw itself (resize it, or draw another window over it).

The same code, when deriving from CDialog works fine.

I could not find a way to force the dialog to repaint itself and get rid of this remains of the controls. RedarwWindow() or Invalidate() on the dialog did nothing.

What am I missing? How can I force the CExtResizableDialog to redraw itself?

Thanks,
Ron.

I am not using group-box.
Also, i am emphasizing that when the clip properties are off there is no problem (but it flickers...) so it seems to me that the class CExtResizableDialog does not do a good job of monitoring when the controls are used using SetWindowPos or BeginDeferWindowPos calls.

That’s what i would like to know what call to make so that the CExtResizableDialog will refresh completly all its content.

Thanks.

Dear Support,

I explored this bug further more, and the cause of the problem is the clip children and clip siblings.
When they are false (default CDialog) the CExtResizableDialog paints itself correctly HOWEVER, it flickers like crazy.
When they are true, there is no flicker, but a lot of garbage is displayed on the dialog.

Can you please send me what command i need to call to redraw the dialog so this garbage will be lost?

Thanks.

The problem may be that you are using a group box on the dialog and the tab order for the controls inside the group box isn’t correct . You can read more about this in the following FAQ article:

I use CExtGroupBox and a set of controls. Some controls are not painted correctly, what may be wrong?

I am not using group-box.

Also, I am emphasizing that when the clip properties are off there is no problem (but it flickers...) so it seems to me that the class CExtResizableDialog does not do a good job of monitoring when the controls are used using SetWindowPos or BeginDeferWindowPos calls.

That’s what i would like to know what call to make so that the CExtResizableDialog will refresh completly all its content.

Thanks.

We tried to reproduce this issue but failed. The dialog background is always painted correctly. Would you send us a test project that demonstrates the problem?

In any case, the Invalidate() method should cause the dialog background to be repainted. You could also try the RedrawWindow() method with the RDW_ALLCHILDREN flag in order to repaint the dialog with all its child windows:

RedrawWindow(
    NULL, 
    NULL,
    RDW_INVALIDATE | RDW_ERASE | RDW_UPDATENOW
        | RDW_ALLCHILDREN | RDW_FRAME
    );

Happy New Year Tech Support,

I would like to ask you about stackable tabs (if that is the right nomenclature). When I have many CExtControlBars stacked into a single bar, the tabs get too small to read the names of the of the different bars from the tabs.

Is there a way to start stacking the tabs, ala property pages, once they reach some minimum size?

Thanks,
-Brett

When clicked, check mark does not stay on in box.

I have a main window with a CExtControlBar that is the parent of a CExtWS< CDialog > derived class.


    class CMainFrame : public CExtNCW < CFrameWnd >, public CExtDynamicBarSite
    

    if ( !_recorderToolbar.Create(L"Capture", this, ID_VIEW_CAPTURE_BAR,
        WS_CHILD | CBRS_RIGHT | CBRS_GRIPPER | CBRS_FLYBY | CBRS_SIZE_DYNAMIC | CBRS_TOOLTIPS))
    {
        TRACE0("Failed to create capture control bar\n");
        return -1; // failed to create
    }

    if (!_recorderDlg.Create(RecorderDlg::IDD, &_recorderToolbar))
    {
        TRACE0("Failed to create capture dialog\n");
        return -1; // failed to create
    }


    
Everything works fine unless I click the pushpin on the control bar. When I click it, I get an assertion on this line:

    ASSERT( ((CExtDockBar*)pWndParent)->_GetCircleNo() > 0 );
    
If I click Ignore on the dialog, everything seems to work fine regardless. In addition, if I drag the control bar from being docked to floating then back to docked, the pushpin works fine and no longer asserts.

What is causing the assertion?

Thanks,
Scott

Thansks, that fixed my ExtControlBar problem.

However, I tried switching my 2 CExtToolControlBar classes to use those methods and it asserts on !IsFixedSize(). So I switched back to CFrameWnd::DockControlBar() and it seems to work correctly. Is this correct or there another method I need to call to dock tool bars?

Thanks,
Scott

You also need to call m_wndMyToolbar.EnableDocking( CBRS_ALIGN_ANY ); for all of your toolbars (and menubar and controlbars). Also, don’t forget to have this code in your CMainFrame::OnCreate before calling any of the CExtControlBar::DockControlBar*** methods:

	if( !CExtControlBar::FrameEnableDocking(this) ){
		ASSERT( FALSE );
		return -1;
	}

Dear Support.
I have my owner-drawn control. In some cases i want it to be disabled. I used to get the disabled clor from the OS using GetSysColor.
But, when my application is themed, this color does not match the scheme anymore.

How can i get the RGB you use for disabled controls?

Thanks,
Ron.

Thanks.

Dear Support,

A while ago you wrote to me:

You cannot use CExtNCW for that. But this already is in our to-do list.

I asked when this feature will be implemented, and got no reply.

I would like to add als well, that if the main-frame is skinned, and you double clisk the bar to restore/maximize mode, you see the blue XP bar flickers for a while.
Can this problem be fixed as well?

Regards,
Ron.

What I ask is to know an estimation as to when this feature will be ready.

As we said before the standard Windows MDI interface is not compatible with a child frame window that implements a custom caption. Particularly the cascade/tile/arrange icon commands do not work. We are working on this issue. The cascade/tile/arrange icon commands are already implemented but there are still some problems left. You can try applying the CExtNCW template to CMDIChildWnd and see what is available by the moment.

As for the blue caption that you see when the application is restoring or maximizing, it is a Windows bug. You can see the same in Office 2007 applications.

What I ask is to know an estimation as to when this feature will be ready.

Happy new year.
A recap of an unanswered problem, hope for a faster reply this time:

Dear Support,

When you right-click and the bars list menu appears, and you are too close to the bottom of the screen, the menu bar is relocated so that it wonaˆ™t be displayed partially.

This feature is required. However, when this happens, the menu is closed too fast (the user must keep the button pressed, or else the menu is closed), before the user get the chance to select a command from the menu.

Regards,
Ron.

Sir,

we are using your latest Prof-UIS 2.6. we are getting huge advantage of your advanced classes.

we have some problem as below.

1. we have added GUI customization support in our application.It is working but after adding customization support if we add new menu through resource it is not added in compiled "Exe" .
we have tested the same in your sample application "DRAWCLI". The same problem we are getting in sample application also.

2. we are also not able to add new icon image in our application but in debug is is working fine.

Please answer as soon as possible.

Hi,

I have a cell of type CExtGridCellUpDown. I need to limit the range of numbers in the cell from 0 to 100.
How do I do this?

Thanks.
Ron.

I can add buttons, edit controls, combos, etc to a group in a ribbon bar.
The ribbon bar does not contains any pure labels in the samples.
The closest things I can find are the Indent and Spacing in the Paragraph group of the ribbon bar samples, but they light up like buttons.


I want labels that don’t light up.

Can I do this and if so how?

There is a CExtBarLabelButton but you cannot yet use it the ribbon bar. We are working on this so you can use it in the ribbon bar. Could you use disabled buttons with text until CExtBarLabelButton is ready?

Hi,

There are question i asked a month ago, and got no response.
Is the technical support on vacation?

Regards,
Ron.

Ribbon Bar Sample.

File Save As

Instead of using something like the below in the sample:
                CExtRibbonNode * pNodeFileSaveAsFormat1 =
                    new CExtRibbonNode(
                        ID_FB_SAVE_AS_FROMAT_ICON,
                        ID_FB_SAVE_AS_FROMAT_ICON,
                        NULL,
                        __ECTN_BIG_ACCENT_IN_MENU|__ECTN_BOLD_IN_MENU,
                        NULL,
                        _T("Save Document As Format 1")
                        );
                pNodeFileSaveAsFormat1->SetTextMenuExtended(
                    _T("Save a copy of that will be fully compatible\nwith Format 1")
                    );
                VERIFY(
                    pNodeFileSaveAsFormat1->m_iconBig.m_bmpNormal.LoadBMP_Resource(
                        MAKEINTRESOURCE( ID_FB_SAVE_AS_FROMAT_ICON )
                        )
                    );
                pNodeFileSaveAsFormat1->m_iconBig.m_bmpNormal.Make32();
                pNodeFileSaveAsFormat1->m_iconBig.m_bmpNormal.AlphaColor( RGB(255,0,255), RGB(0,0,0), 0 );
                pNodeFileSaveAs->InsertNode( NULL, pNodeFileSaveAsFormat1 );

I would like the save as menu to be a collection of edit controls of which I need the data from all of them for a save as command.

Can you send me a sample that uses 2 edit controls/boxes and and 2 static boxes that identify those edit controls as well as maybe an OK button to indicate the save as command should be processed.

Please take a look at the Style menu in the menu bar in the StyleEditor sample. It has the Style, Font and Size combo box items. Each of them has a label on the left side of the combo box control’s area. It is possible to create the same edit boxes in menus. Is that what you need in the submenu displayed from the Save As item in the ribbon bar’s file menu?

Yes, I will play with it

Sorry, this isn’t going to work after all.

I want the ability of a dialog in the file save function where several edit controls need to be completed before the file save as command is executed. I was also hoping it would appear in the menu area.

That sample only allows one item to be completed and then the menu goes away.

The CExtPopupCtrlMenuWnd class is derived from CExtPopupMenuWnd and implements special kind of popup menu which contains one HWND-based child window instead of a set of classic menu items. The CExtPopupCtrlMenuWnd class is used as the base class for list-box menus, undo-redo menus and ribbon gallery menus. It is possible to code dialog container menu and use it anywhere in any menu tree but this task is tricky. Unlike dialog windows, menus never get system focus. So embedding dialog into menu is a kind of custom task. Please let us know why you need a dialog like menu with editors instead of a popup dialog?

I have decided that a ribbon bar interface wants to keep context rolling. I agree.
So, when I click a ribbon bar item and it represents more than a menu selection (dialog), I want to keep the user context close.

So, for example, I catch the following:
void CMainFrame::OnCommand1( )
{
    RECT rect ;
    CmdIDtoRect( ID_SHOW_HIDE_RULER, &rect ) ;
}

where:

int CMainFrame::CmdIDtoRect( UINT command_id, LPRECT lpRect )
{
    int index = m_wndRibbonBar.CommandToIndex( command_id ) ;
    m_wndRibbonBar.GetButtonRect( index, lpRect ) ;
    return( index ) ;
}

I now know the location of the ribbon button and can drop below the button a dialog based on the ribbon button’s rect location as above.

This way I maintain context. For example, I could use an Options button in the ribbonbar. It is clearly a dialog. By clicking it, the options dialog drops below the button. User Context is maintained. Maybe it should be in a file menu, maybe not.

Normally, a dialog would appear in the middle of the program screen and context is lost. I don’t like this.


So, my "file save as" command involves three edit controls and it is impossible to use a menu. Based on this fact, system or program focus is necessary because each of the 3 edit controls must be executed and delivered before focus is breached. But, I want to maintain context.

So, if you could tell me how I can get the coords of that list control to the right of the file menu, I will drop my own dialog on top of it. In addition, I can’t figure out where the OnClick is for the buttons in the file menu. I need that to know when to drop the dialog when the "File Save As" button is Clicked.

Take your time.
Many thanks,
Andrew Banks

We have a class derived from CExtGridCell with an OnPaintText override implemented to provide custom text rendering inside the cell. Upon the upgrade to the Prof-UIS 2.62 release, we find that this override is not being called and nothing is being painted inside the window. Is there something we are missing in the initialization of the cell??
Thanks and have a Happy New Year.

The signature of the CExtGridCell::OnPaintText() method has not been changed. Could you insert your grid cell class into some grid in the SimpleGrids sample and send the modified code to us? We guess there must be something wrong with linking LIB files or a problem with include paths.

We wish you a Happy New Year too.

Problem seemed to be that the OnPaintForeground was calling IsEmpty() for the cell before calling OnPaintText. My cell did not implement the IsEmpty call and was returning true. Solution was to MyCell::IsEmpty() {return false;}

I need some of my dynamic control bars to be destroyed on close window button click, and to keep standard behavior (hide) to others. Tell me please how can I do this?
I’v overridden BarStateSet() method, in which I close dynamic control bar by calling BarFree() and returnig false as a result. This manner worked till 2.62 version has been released. In version 2.62 the result of BarStateSet() call is ignored in CExtDynamicControlBar::NcButtons_PostClick() method and CExtControlBar::NcButtons_PostClick() is always called while I’ve already destroyed this control bar.
Is my solution correct or I need to do something else?

Dear Support,
How can i get the version 2.63.2?
Regards,
Ron.

Dear Gevork,
I was facing the same problem, and could not find a good solution - my problem was when having few bars tabbed, or side-by-side.
Did you try it in one of these methods? did the application work properly?
Thanks,
Ron.

Here is the final part of the CExtDynamicBarNcAreaButtonClose::OnNcAreaClicked() method:

    if( pBar != NULL )
        pBar->BarStateSet( pBar->BarStateGet(), false );
    if(    hWndBar != NULL
        && ::IsWindow( hWndBar )
        )
        pExtBar->NcButtons_PostClick( this, point, pExtBar, NULL );
    return true;

As you can see CExtDynamicControlBar::NcButtons_PostClick() should not be invoked if the CExtDynamicControlBar::BarStateSet() method destroys the CExtDynamicControlBar window.

We added the following method to the CSimpleControlBar class in the SDI_DynamicBars sample in order to so demonstrate how to destroy dynamic control bars correctly:

    virtual bool BarStateSet(
        eDynamicBarState_t eDBS,
        bool bShow
        )
    {
        if( bShow )
            return CExtDynamicControlBar::BarStateSet( eDBS, bShow );
        GetBarSite()->BarFree( this );
        return false;
    }

Thanks. But where can I download this sample? I’ve downloaded the 2.631 version but I cannot find it.

When I try to build the DLL version of Prof-UIS V2.62, my Visual Studio 2005 will be crash !

I had three computer, 2 PC and 1 Notebook. My home’s PC is a new installed OS and Visual Studio 2005 (Without install Trial v2.62 before) . In this case, the Prof-UIS will be build successfully (by Integration Wizard).
But my office’s PC and Notebook both crash when using "Integration Wizard" or direct build in Visual Studio 2005. My office’s PC and notebook Both install and uninstall Pro-UIS trial v2.62, and before uninstall the trial version, I using "Integration Wizard" to do remove first.)

Could you help me to fix this problem ? Thanks.

Please let us know more about your two computers: OS details, type of Visual Studio 2005 and any additional software installed on them (anti virus, anti spyware, Visual Studio 2005 extensions, newer Platform SDKs, etc.).

In my workable PC (One is Windows XP with SP2, One is Windows Vista Ultimate English).
I also installed the following software.
1. Visual Studio 6.0 Professional with SP6.
2. Visual Studio .Net 2003 Professional with SP1 (English)
3. Visual Studio 2005 Professional (English)
4. Symantec AntiVirus Corp version 9.0.1.1100 (Win XP Only)
5. Windows XP DDK (2600.1106)

Not installed.
1. DirectX SDK.

Thanks for your support.

Both PC and Notebook had installed the following software :
1. Windows XP SP2 with all new update.
2. Visual Studio 6.0 Professional with SP6
3. Visual Studio .Net 2003 Professional with SP1 (English)
PC with VB installed. Notebook without VB install.
4. Visual Studio 2005 Professional version with new update from Microsoft Web site. (English)
VC#, VC++ Install only.
5. Symantec AntiVirus Corporat version 9.0.1.1000 (Taiwan Chinese version)
6. Windows XP DDK (2600.1106)
7. DirectX SDK (April 2006)
8. MSDN Library

It seems the problem has to do with that your OS is one of the Asian versions of Windows. There may be a problem with character translation in the resource compiler. We cannot reproduce the problem. There are the following workarounds:

1) Edit the ..\Prof-UIS\Include\Resources\resource.rc file and uncomment the lines relating to the languages you do not actually need:

//#define __EXT_MFC_NO_RESOURCES_***

2) Compile Prof-UIS on a machine where English Windows OS is running

3) Change the OS language to English (Control Panel | Regional and Language Options | Advanced), compile Prof-UIS and then return the settings back.

Dear Supporter,

Thank for your reply. About this probem, I think it may not a OS problem, because in new installed Chinese OS (XP), it work well.
Please try to install your Trial version first and uninstall it, and then install Prof-UIS v2.62. It may reproduce this problem (I hope).
Thanks.

P.S : Uncomment the lines in resource.rc is still not work.

Unfortunately we do not have the Chinese OS installed. Did you try to change the OS language to English and compile the library?

The x button at the top of a CExtControlBar is used to Hide the control bar. How can I use this to close the control bar and remove if from the Frame.

Dear Support,

I have asked a while ago to make this function part of the library, as it have demand.
Also, i think that you should do a sample, and test this feature, as this function and it’s usage cause bugs elsewhere.

Regards,
Ron.

If you are using CExtControlBar control bars, you should override the OnNcAreaButtonsReinitialize() virtual method. You can make it the same as the original method except for instantiating your own CExtBarNcAreaButtonClose-derived object which implements the "X"-button in the bar’s caption. In this Close button class, implement the CExtBarNcAreaButton::OnNcAreaClicked() virtual method which is invoked when the caption button is clicked. Your version of this method should invoke the following function to remove the control bar:

#include "../Src/ExtDockBar.h"
#include "../Src/ExtControlBarTabbedFeatures.h"

void KillBar(
    CExtControlBar * pBar,
    bool bForceNoOptimizeMode = false
    )
{
    ASSERT_VALID( pBar );
    ASSERT_VALID( pBar->m_pDockBar );
    ASSERT_VALID( pBar->m_pDockSite );
CFrameWnd * pDockSite = pBar->m_pDockSite;
    ASSERT( pDockSite->GetSafeHwnd() != NULL );
CMiniDockFrameWnd * pMiniFrame = NULL;
    if( pBar->IsFloating() )
    {
        pMiniFrame = 
            DYNAMIC_DOWNCAST(
                CMiniDockFrameWnd,
                pBar->GetDockingFrame()
                );
        ASSERT_VALID( pMiniFrame );
    } // if( pBar->IsFloating() )
    else
    {
        ASSERT( ! pBar->m_pDockBar->m_bFloating );
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
        if( pBar->AutoHideModeGet() )
        {
            ASSERT_KINDOF( CExtDockBar, pBar->m_pDockBar );
            CExtDynAutoHideArea * pWndAutoHideArea =
                ((CExtDockBar*)pBar->m_pDockBar)->_GetAutoHideArea();
            ASSERT_VALID( pWndAutoHideArea );
            CExtDynAutoHideSlider * pWndSlider =
                pWndAutoHideArea->GetAutoHideSlider();
            ASSERT_VALID( pWndSlider );
            if( (pWndSlider->GetStyle()&WS_VISIBLE) != 0 )
                pWndSlider->SendMessage( WM_CANCELMODE );
            pWndAutoHideArea->RemoveControlBar( pBar, true );
        } // if( pBar->AutoHideModeGet() )
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
        if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockBar)) )
        {
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
            if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockDynTabBar)) )
            {
                CExtDynTabControlBar * pTabbedBar =
                    STATIC_DOWNCAST(
                        CExtDynTabControlBar,
                        pBar->m_pDockBar->GetParent()
                        );
                LONG nIdx = pTabbedBar->FindControlBar( pBar );
                if( nIdx >= 0 )
                {
                    LONG nSel = pTabbedBar->GetSwitcherSelection();
                    if( nIdx != nSel )
                        pTabbedBar->SetSwitcherSelection( nIdx );
                    pTabbedBar->RemoveSelFromSwitcher();
                } // if( nIdx >= 0 )
            } // if( pBar->m_pDockBar->IsKindOf(RUNTIME_CLASS(CExtDockDynTabBar)) )
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
            VERIFY(
                ((CExtDockBar *)pBar->m_pDockBar)->
                    RemoveControlBar( pBar, -1, 0, false )
                );
        }
        else
        {
            VERIFY( pBar->m_pDockBar->RemoveControlBar(pBar) );
        }
    } // else from if( pBar->IsFloating() )
    pDockSite->RemoveControlBar( pBar );
    pBar->m_pDockSite = NULL;
    pBar->m_pDockBar = NULL;
    if( pMiniFrame != NULL )
        pMiniFrame->DestroyWindow();
    else
        pBar->DestroyWindow();
    if( ! bForceNoOptimizeMode )
        CExtDockBar::_OptimizeCircles( pDockSite );
}

Please note that if you remove simple control bars (the CExtControlBar objects), there may be problems with saving/restoring the state of control bars to/from the registry. So for simple control bars, just to hide them would be a better solution.

The dynamic control bars (the CExtDynamicControlBar objects) controlled by the dynamic bar site (the CExtDynamicBarSite object) can be safely removed and allocated any time and the CExtDynamicBarSite object restores the recent number of dynamic control bars using runtime type information of each dynamic bar for restoring exactly the same object. You can use the above described approach for dynamic control bar, but you should code your own CExtDynamicControlBar-derived and CExtDynamicBarNcAreaClose-derived classes. The close button class in this case should invoke the CExtDynamicBarSite::BarFree() method to de-allocate the control bar. Dynamic control bars are demonstrated in the SDI_DynamicBars and MDI_DynamicBars samples. These bars have additional features like switching into document mode and more. These bars can be mixed with the simple control bars in scope of one frame window.

The above code works thanks. However,

    int sz = pMiniFrame->m_wndDockBar.m_arrBars.GetSize() ;
    for (int i = 0; i < sz; i++)
            pMiniFrame->m_wndDockBar.m_arrBars[i] = NULL;

Needs to be added before Destroy Window. The destruction code eventually reaches CDockBar::~CDockBar() in MFC on the variable CMiniDockFrameWnd::m_wndDockBar. The array m_wndDockBar.m_arrBars becomes invalid prior to CDockBar destruction and so occasional asserts occur in the destruction code of CDockBar. The alternative is to use CMiniDockFrameWnd::m_wndDockBar.RemoveControlBar and not directly call DestroyWindow on the CMiniDockFrameWnd as CDockBar::RemoveControlBar() does that for you once all control bars are removed.