Forum

Working with ProfUIS 2.32.

Problem #1: Tab-docked control bars don’t get visibility correct when Autohidden

I notice that when ControlBars are tab-docked together and AutoHidden, CControlBar::IsVisible() always returns 1.
When a ControlBar is AutoHidden by itself (not tab-docked with any other bar), CControlBar::IsVisible() returns 0.

Problem #2 (possibly related to #1): Autohide controlBar will "grab" all other hidden controlbars that are tab-docked with it, and show their tabs, regardless of their visibility state.

To reproduce in MDI_DynamicBars project:
-Tab-dock Bar4 and Bar5 together
-Close Bar4
-Autohide Bar5

You’ll see that Autohide tabs appear for Bar5 (good) AND Bar4 (wrong, should be hidden). The Autohide tab for Bar4 should not appear until pBar4->BarStateSet( pBar4->BarStateGet(), TRUE) is called.

Is it possible to get a workaround to these problems? Thanks!

If you are using CExtDynamicControlBar-based bars based on the CExtDynamicBarSite instance, just use the CExtDynamicControlBar::BarStateGet() method which returns both the state of the control bar and visibility flag in this state.

In case of ordinary non-dynamic control bars, there is no such a convenient method. The control bar in the auto-hide mode is the ordinary control bar, which is hidden, the auto-hide flag is turned on and it has the associated tab item in the grouped auto-hide tabs area. So, you need to start analyzing the state of such a control bar with the CExtControlBar::AutoHideModeGet() method.

As for auto-hide tab behavior, we cannot say that this is a bug but rather particular implementation of resizable control bars in Prof-UIS. If you believe that this should be changed in a way you described we are ready to discuss this.

It makes sense to use BarStateGet() instead of IsVisible(): you definitely have behaviour above and beyond standard MFC controlbars that deserves its own method.

I believe however, that if a control bar is hidden, it should always remain hidden until we request to show it.
In the case I describe above, Bar4 becomes "visible" (we can see its autohide tab) simply because it happened to be tab-docked with another controlbar that is being auto-hidden.

Under this condition, I believe that Bar 4 should remain hidden, but should remain tab-docked with Bar5. This way, once I make Bar4 visible, it remains tab-docked with Bar5. Since Bar5 is currently auto-hidden, Bar4 should also be in the same auto-hide state, and we should now see an additional Auto-hide tab for Bar4.

I’m guessing that your current approach is that tab-docked control bars act together as a "group": close one, and you close them all. Show one, and you show them all.
I agree that their docking state should be a "group decision": since the user has decided to group them together, they should travel together (auto-hide, floating, etc).
My point is that I believe control bar visibility is not a "group decision", they should be individually controlled.

We tend to agree with your point of view with regard to improving the behavior of resizable control bars that are tab-docked and added this issue to our to-do list. Such independent control of control bars’ visibility may be convenient.

I also found that a similar visibility problem also occurs when floating tab-docked controlbars together: close the floating window (use "X" button), and I find that BarGetState(&isVisibile) returns (isVisible == true), which is wrong.

Perhaps if you could try something to your sample project MDI_DynamicBars, you’ll get a chance to see how controlbar visibility isn’t quite right yet, and will also demonstrate the issues that I’ve raised:
Currently, r/click popup-menus list all toolbar and controlbar names (and their icons), but do not indicate controlbar visibility status (as is done with toolbars). Selecting a controlBar will make it visible (if it was hidden), but the inverse it not true: it does not close the control bar.

If you made the r/click menu behave the same way for controlbars as it does for toolbars (indicate and TOGGLE visibility state), this should demonstrate these issues well. Heck, it would also make this superb example even better!

The toolbars (CExtToolControlBar) and other fixed size control bars including the panel control bar (CExtPanelControlBar), menu bar (CExtMenuControlBar) and status bar (CExtStatusControlBar) are docked next to outside frames. All these control bar types use the show-hide behavior of their commands and Prof-UIS automatically generates checked-states of all the commands corresponding to the fixed size bars. As for resizable control bars (CExtControlBar, CExtDynamicControlBar) they can show two types of behavior regarding to show/hide commands:

1) Old style behavior which you can use only if the auto-hide feature is not enabled for the frame window, i.e. you do not call the CExtControlBar::FrameInjectAutoHideAreas() method. This behavior is absolutely similar to the behavior of commands corresponding to the fixed size control bars.

2) New style behavior introduced in Visual Studio .NET. It can be described as one-way action. By performing the command corresponding to a resizable control bar, you can only show this bar and set focus onto the child window of this control bar. If the auto-hide feature is enabled in your application, such behavior is mandatory.

The CFrameWnd class has two handy methods which you can use in the message map entries of your frame windows: OnBarCheck() and OnUpdateControlBarMenu(). These methods implement the old style command behavior for control bars. You cannot use these methods with resizable control bars when the auto-hide feature is enabled. So, in many our samples we re-defined these methods in the CMainFrame class. Here is our version of these methods:

#define USE_OLD_STYLE false
 
BOOL CMainFrame::OnBarCheck(UINT nID)
{
   return CExtControlBar::DoFrameBarCheckCmd( 
      this, 
      nID, 
      USE_OLD_STYLE 
   );
}
void CMainFrame::OnUpdateControlBarMenu(CCmdUI* pCmdUI)
{
   CExtControlBar::DoFrameBarCheckUpdate( 
      this, 
      pCmdUI, 
      USE_OLD_STYLE 
);
}

If we change the definition of the USE_OLD_STYLE preprocessor symbol to true, then these methods will work like the same methods in the CFrameWnd class.

We will additionally check the "X" button click problem for complex floating palettes.

1. Can I get a suggested workaround to the tab-docking visibility issue when autohiding CExtDynamicControlBar?


2. Yes, I can understand the differing functionality of OnUpdateControlBarMenu() and OnBarCheck(), and how to modify their behaviour when enabling Autohiding.
However, your sample project MDI_DynamicBars does not display visibility status of each CExtDynamicControlBar, nor does the code toggle visibility: it only *shows* control bars, does not hide them.

By example, r-click in toolbar area: popup menu shows a checkmark if toolbar is visible, no checkmark if toolbar hidden. Selecting "Toolbar" menu option will toggle visibility.

My point was that if you performed the same functionality for all CExtDynamicControlBar, this will demonstrate the visibility problems that I describe.


3. It has become very confusing as to how to check visibility of CExtDynamicControlBar, and how to toggle visibility. A working sample would greatly clarify and demonstrate the correct implementation.

By example, this no longer works correctly:
MyCExtDynamicControlBar::OnFrameBarCheckUpdate()
{
...
pCmdUI->SetCheck( (GetStyle() & WS_VISIBLE) != 0 );
...
}

And under the circumstances I mentioned earlier, neither does this:
BOOL IsControlBarVisible()
{
bool bIsVisibleState = false;
BarStateGet(&bIsVisibleState))
return bIsVisibleState? TRUE : FALSE;
}

So, can you advise what is the correct technique to check for visibilty of CExtDynamicControlBar? How would you implement IsControlBarVisible()?

Please let us to simplify and clarify your current task description before we will provide you with the ready-to-use solution: everything is OK, but you want to see check marks on the resizable bar commands even if auto-hide feature is enabled. Is that what you need right now?

No.
I thought it would have been useful to demonstrate how BarStateGet(&bIsVisible) returns the wrong values under certain circumstances, but I no longer believe it will solve the problems we’re trying to solve, and I’ve also veered waaaaay off track. So let’s backup a bit....

Your implementation emulates VS .NET behaviour, and VS.NET does not show checkmarks for visible controlbars: So, your sample project emulates VS.NET behaviour (good!) except for the following. So, what I really need are these 2 items:


1. A fix for the problem originally posted in this thread:

"To reproduce in MDI_DynamicBars project:
-Tab-dock Bar4 and Bar5 together
-close Bar4 (use "X" button on NCarea)
-Autohide Bar5
You’ll see that Autohide tabs appear for Bar5 (good) AND Bar4 (wrong)."

I can also duplicate same condition when closing Bar4 with BarStateSet( BarStateGet(), false ) instead of close button.

VS .NET doesn’t behave this way, I don’t believe ProfUIS should either. If you disagree, that’s fine, but could you please show me how I can work around this?


2. A fix for BarGetState(), or a demonstration of how to implement CExtDynamicControlBar::IsControlBarVisible() that works for all possible states.

As mentioned earlier in this thread:
"when floating tab-docked controlbars together: close the floating frame window (use "X" button), and I find that BarGetState(&isVisibile) returns (isVisible == true), which is wrong."

1. Yes, we agree with your comments regarding independent auto-hide/hide behavior of resizable control bars in tabbed groups. We have already added this to our to-do list.

2. We fixed the bug with closing the floating palette and now performing some additional tests. This will be available in the Prof-UIS 2.32 intermediate release which we plan to publish this week.