Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS General Discussion » CExtToolControlBar in MDI Applications Collapse All
Subject Author Date
Sergio Buonanno Mar 1, 2006 - 9:20 AM

I have an MDI application with each of the MDI child windows containing a dialog and a toolbar of type CExtToolControlBar. The toolbar is a child of the MDI child window, not of the dialog. See the editor window of VS 2005 for an example; it has 2 combo boxes: one for the classes and the other one for the member functions. In my case I have just buttons, not controls.
I’m have 3 problems:

1) I cannot set a 3D background for the toolbar as the MDI Frame Window toolbar has.
2) Sometimes the application fails to load the serialized state from a file (I use g_CmdManager->SerializeState and CExtControlBar::ProfileBarStateSerialize and a CArchive object to serialize the GUI state on a disk file), because it looks like Prof-UIS framework is trying to load the state of the toolbars of the MDI child windows I opened before (MDI child windows toolbars can be different from one another), but those toolbars (and their parent windows) do not exist when the application starts. Is there a way to skip state serialization for a particular toolbar ?
3) Is there the possibility to access the MDI child window toolbar by keyboard or create a popup menu from the MDI child’s toolbar ?

Thanks

Sergio Buonanno Mar 1, 2006 - 12:46 PM

Thank you for your help, but something is still missing. Is there any way to skip state serialization of a toolbar ? I have some fixed toolbars (those that are child of the MDI child window) I don’t want to save the state of.

Thanks

Technical Support Mar 1, 2006 - 11:36 AM

If you want to see a balloon background in a non-redockable toolbar, just set its CExtToolControlBar::m_bForceBalloonGradientInDialogs property to true. You can look into your frame initialization destruction code to find out why the state is serialized unsuccessfully. You can assign HMENU to any button in the toolbar not depending on whether it is enabled for the drag-and-drop based redocking. The CExtToolControlBar::SetButtonMenu() attaches a menu to a toolbar button. It is possible to make your non-dockable toolbar working with keyboard. You need to pre-translate keyboard messages in your child frame window and analize whether a aprticular key combination relates to toolbar buttons. The CExtToolControlBar::GetButtonByAccessKey() method returns a button index by the pressed accelerator key. The search is based on looking up underlined characters in the text of toolbar buttons.

CExtToolControlBar * pToolBar = . . .
int nBtnIdx = pToolBar->GetButtonByAccessKey( . . . );
    if( nBtnIdx < 0 )
        return;
CExtBarButton * pTBB = pToolBar->GetButton( nBtnIdx );
    ASSERT_VALID( pTBB );
    ASSERT( ! pTBB->IsSeparator() );
    if( ! CExtPopupMenuWnd::IsMenuTracking() )
    {
        HWND hWndFocus = ::GetFocus();
        if( hWndFocus != NULL )
            ::SendMessage( hWndFocus, WM_CANCELMODE, 0L, 0L );
    } // if( ! CExtPopupMenuWnd::IsMenuTracking() )
    if( pTBB->IsAbleToTrackMenu() )
        pToolBar->TrackButtonMenu(
            nBtnIdx,
            true,
            false,
            false
            );
      else
        pTBB->OnDeliverCmd();


Sergio Buonanno Mar 2, 2006 - 12:22 AM

Thank you for your help, but something is still missing. Is there any way to skip state serialization of a toolbar ? I have some fixed toolbars (those that are child of the MDI child window) I don’t want to save the state of.

Thanks

Technical Support Mar 2, 2006 - 2:09 AM

You wrote "have some fixed toolbars (those that are child of the MDI child window)". If these toolbars are not enabled for drag-and-drop-based re-docking like the status bar window, then you do not need to think about whether their state is saved or not. If they are ordinary toolbars that support drag-and-drop, then just redock and show/hide them in the desired initial positions independently from whether their state is loaded successfully. We do not support serialization separately for a particular toolbar because the state of each bar (toolbar or resizable bar) mutually depends on the state of the neighborhood bars. In case of toolbars, the state dependency is based on the toolbar’s persistent affixment feature provided by Prof-UIS toolbars, which allows the toolbar being dragged with the mouse to move other toolbars in the same row/column. So, even if you forcibly re-dock some toolbars after their state is loaded, we cannot guarantee their positions will be those you expect.