Forum

Hello,

I need to make all CExtDynamicControlBar windows, that are contained in the same floating container, visible with one menu command, when this floating container is hidden.

Imagine a scenario, where three CExtDynamicControlBar windows are docked in the same floating container, are hidden by pressing the X of this container. It should now be possible, to make these windows visible again with one single menu command.

With the menu item associated with the control bar ID of one of these bars it is just possible to make one bar visible at a time. Thus the user would have to select three menu items, to make all bars contained in that floating container visible again (can be reproduced with your MDI_DynamicBars example).

I tried the following approach:

if (GetParentFrame()->IsKindOf(RUNTIME_CLASS(CMiniFrameWnd)) &&
(!GetParentFrame()->IsWindowVisible()))
{
    CFrameWnd* poMainFrame = (CFrameWnd*)AfxGetMainWnd();

    POSITION pos = poMainFrame->m_listControlBars.GetHeadPosition();
    while (pos != NULL)
    {
        CControlBar* poBar = (CControlBar*)poMainFrame->m_listControlBars.GetNext(pos);

        if ((poBar != NULL) &&
        (poBar != this) &&
        (poBar->IsKindOf(RUNTIME_CLASS(CExtDynamicControlBar))) &&
        (poBar->GetParentFrame() == GetParentFrame()))
        {
            CExtControlBar::DoFrameBarCheckCmd((CFrameWnd*)AfxGetMainWnd(), poBar->GetDlgCtrlID(),false);
        }
    }
}
CExtControlBar::DoFrameBarCheckCmd((CFrameWnd*)AfxGetMainWnd(), GetDlgCtrlID(),    false);

The above code shall make all "sibling" bars visible, too, when one of these bars is about to become visible.

This works well, when all bars are tabbed in the floating container. When all bars are docked, then all bars become visible. However, the new size, which is assigned to each of these bars is different from their former size, when the X was pressed to close the floating container. In other words: the bars are not restored with their previous size.

Any ideas how to avoid this effect?

As you know the feature you want to implement is not supported in the Visual Studio-style docking. There is no way in Visual Studio to make all control bars in a floating group visible at once. But the behavior you requested sounds reasonable and will certainly be handy for users. However to implement it as a general feature requires time and effort. At the moment, we can offer you another solution. There is a StateInFile sample in Prof-UIS, which allows the user to state the UI state into a file. So the solution could be to save the state of grouped control bars into a file ( or under some registry key) and then when the user clicks a menu item or button, this state is restored and the user can see all the control bars restored into their floating container.

Hello,

many thanks for considering this request as a general feature.
>>
At the moment, we can offer you another solution. There is a StateInFile sample in Prof-UIS, which allows the user to state the UI state into a file. So the solution could be to save the state of grouped control bars into a file ( or under some registry key) and then when the user clicks a menu item or button, this state is restored and the user can see all the control bars restored into their floating container.
<<
This sounds like a rather tricky workaround. Could you please tell me, how to serialize the state of just those control bars to a CArchive, that are grouped together in a floating container? I would prefer to use a CMemFile as a temporary storage for the state of the affected control bars.

The CExtControlBar::ProfileBarStateLoad() and CExtControlBar::ProfileBarStateSave() static methods are used in the most of Prof-UIS samples for loading /saving the control bar state from/to the system registry. The CExtControlBar::ProfileBarStateSerialize() static method also laods/saves the state but it uses the reference to the CArchive object as parameter. This archive can be based either on the CMemFile memory file object or on the CFile file object on disk.

Yes, I am aware of these methods. But as far as I understand, these methods will save and restore the state of ALL bars. This will very probably not solve my problem.

CExtControlBar::ProfileBarStateSerialize() will probably restore the status of ALL bars with regard to the moment, when the floating container with the grouped bars was hidden. While the floating container was hidden, some other "third party" bars may have changed their status. These status changes would be reset, too, when CExtControlBar::ProfileBarStateSerialize() is invoked, correct?

For this reason it is necessary, just to serialize only the state of the grouped bars, but nothing else. Is this possible and if so, how?

The CExtControlBar::ProfileBarStateLoad(), CExtControlBar::ProfileBarStateSave() and CExtControlBar::ProfileBarStateSerialize() methods allow you to load and save the state of the following control bars:

1) All the control bars.
2) Only the fixed-size toolbars (menu bar, toolbars, palette bars, status bar and other bars located in outer frame areas).
3) Only the resizable control bars.

Actually the feature of serializing the UI state of a separate group of control bars is not supported. As said earlier, we developed the CExtControlBar windows to be similar to the dockable panes in Visual Studio .NET and Visual Studio 2005. In fact there is no ready-to-use solution that would allow you to restore the positions of several control bars at once. We can only add this to our to-do list. But in any case, when we are ready to start working on this, we will have to carefully think over every detail.

Hello,

Understood. I appreciate very much, that you put it on your to do list. This will be a feature, which is very handy for many end users.

Hello,

>>
However, the new size, which is assigned to each of these bars is different from their former size, when the X was pressed to close the floating container. In other words: the bars are not restored with their previous size.
<<
It is possible to reproduce a similar problem with the MDI_DynamicBars sample:

1. Dock two dynamic bars together in the same floating frame.
2. Hide the left bar by clicking the X in the NC area of the left bar.
3. Make the left bar visible via the menu.

Both bars are restored with their previous size.

So far so good.

Now:

1. Dock two dynamic bars together in the same floating frame.
2. Hide the right bar by clicking the X in the NC area of the right bar.
3. Make the right bar visible via the menu.

This time the bars are not (!) restored with their previous size.

Even more: if the "hide and show" procedure for the right bar is repeated several times, then the right bar gets smaller and smaller each time. If this procedure is repeated with the left bar, then both bars maintain their size.

From my point of view this is a (small) bug and I guess, that the solution for this effect will probably also solve my original problem.

Hello,

playing further with the MDI_DynamicBars I found another problem, that can be easily reproduced:

1. Start the sample with a cleared registry.
2. Dock Dynamic Bar 1, Dynamic Bar 2 and Dynamic Bar 3 within the same floating container, 1 on the left, 2 in the middle, 3 on the right.
3. Press X in the NC area of the floating container to hide all three bars in one step.
4. Now select the menu item, that belongs to bar 3.

Nothing happens. I would expect, though, that the container becomes visible again with bar 3 as the only content. A bug?

We failed to reproduce this problem with the latest Prof-UIS source code you can download from our web site (i.e. 2.63.3 or 2.63.4).

Additionally, the state of the dynamic control bars should be managed using the CExtDynamicControlBar::BarStateGet() and CExtDynamicControlBar::BarStateSet() methods. If you want to make the bar visible without changing its state, you can do this by calling pDynamicBar->BarStateSet( pDynamicBar->BarStateGet(), true ).

If you need to show and activate (set focus to bar’s child window) only one control bar (simple or dynamic) in any state except for the document state of dynamic bar, then you should send the WM_COMMAND message to the main frame window and specify bar’s dialog control identifier as the command identifier: pMainFrame->SendMessage( WM_COMMAND, WPARAM( pBar->GetDlgCtrlID() ), LPARAM( 0 ) ).

It is not possible to display/activate more than one bar in the auto-hidden mode. This is a limitation of the auto-hiding feature by its design.

Hello,

>>
We failed to reproduce this problem with the latest Prof-UIS source code you can download from our web site (i.e. 2.63.3 or 2.63.4).
<<
the following bug still persists in Version 2.63.3:

1. Start the MDI_DynamicBars sample with a cleared registry.
2. Dock Dynamic Bar 1, Dynamic Bar 2 and Dynamic Bar 3 within the same floating container, 1 on the left, 2 in the middle, 3 on the right.
3. Press X in the NC area of the floating container to hide all three bars in one step.
4. Now select the menu item, that belongs to bar 3.

Nothing happens. I would expect, though, that the container becomes visible again with bar 3 as the only content.

We could not try with 2.63.4, because on the contrary to your statement we didn’t find this version on your web site.

Hello,

>>
It is not possible to display/activate more than one bar in the auto-hidden mode. This is a limitation of the auto-hiding feature by its design.
<<
I was not referring to bars in auto-hidden mode. I meant several bars, that are docked or tabbed in the same floating container.

Assume a scenario, in which a user has arranged - say - three docked bars side by side in a floating container. He is able to hide the complete container (including all three bars) with one single click to the X in the upper right corner of the container. But he is not able to make the container with all three bars visible again with one click. Instead he has to go to the menu three times and to click to each particular menu item, that belongs to each bar.

In our applications we make very extensive use of such bars. It is even possible, that users arrange 5 or even more bars this way. I don’t find it very convenient for the end user to force him to select 5 or even more menu items in order to make a window visible again in the same arrangement as before, that he closed before with one click to an X.

Hello,

>>
We failed to reproduce this problem with the latest Prof-UIS source code you can download from our web site (i.e. 2.63.3 or 2.63.4).
<<
We will verify this as soon as an official release (incl. installer) of this or a subsequent version is available.

We confirm that this bug does occur. The bug fix will be soon available. Thank you.