Forum

Thank you in advance for your help.

I would like to be able to dock two dialogs that are in control bars together, and then be able to auto-hide this pair as a group, so that when I select the tab both windows come out in their most recent placement.

Does my question make sense and is it possible to get this behavior?

Thanks again,
Seth Strong

I can see where I wasn’t clear on this. The group I’m imagining is made of multiple dialogs that were in other control bars so they have docking capability. These dialogs are then docked together so you can see both of them (like a splitter setup). Now currently if this set of dialogs was floating then you would see an additional border of the dynamic control bar that is made to hold the dialog. You can actually use this new border to hide the whole group. I also want to be able to re-display the whole group. And when I dock my set of dialogs, I still want to see an additional caption bar which lets me autohide the set of dialogs so that the arrangement of the dialogs remains.

I put a simple graphic at http://www.marinesonic.com/images/sstrong_PROFUIS_idea.jpg .
It is meant to give you the idea of two dialogs docked together and also docked as a group against the left or right of the CMainFrame with an additional caption for the group so I can pin and unpin the set of dialogs (or rip them separate by their individual captions or whatever).

After that, I just described how I felt this group could be organized into the pop-up menu made by the Prof-UIS framework that I can use to hide or display child windows. By my understanding, there are two parts you don’t support.

1. You don’t save a subset of the layout which would allow users to auto hide and to redisplay a group of dialogs that are docked together by means of the X on the caption to hide and using the right click menu to show the group.


2. 
   You can dock two dialogs together on the side of a frame while they are both "pinned" open so they are shown as desired. But you cannot unpin both so that they open and close as one.
   

Using a tab container is a convenient way to display 1 window at a time of a group, I think it would be very useful to have support for sets of windows as I have described.

Thank you for clarifying your question. It seems you need to create a resizable control bar and then create a static CExtSplitterWnd window inside it with two rows and one column. Finally you should create two dialogs as splitter pages. The dialogs should simply be created as children of the splitter and then you should assign correct dialog control identifiers to them:

pSomeDialog->SetDlgCtrlID( pSplitterWnd->IdFromRowCol( ... ) )

Hello,

it seems that Seth is demanding exactly the same, what we have desired several times before, too.

The approach with the CExtSplitterWnd resolves only the scenario, where it is clear at COMPILE TIME, how the permanent control bars are hosted by dynamic control bars (to use Seth’s terminology here). What we are desiring (and what Seth may desire, too) is to offer the possibility, to arrange permanent control bars in dynamic control bars AT RUNTIME in an arbitrary manner and to give the end user the possibility, to hide and restore such dynamic control bars in one step.

Among others it is necessary for this purpose, to give the end user access to such hidden dynamic control bars; the cascaded menu and the naming convention as outlined in Seth’s article from Jul 16 - 21:31 PM is an excellent idea and I support it. Today only the permanent control bars are available as manageable objects; only these bars can be accessed through the auto-menu, while hidden. Once hidden, however, these permanent control bars are always restored as "isolated" objects from the end user’s point of view.

End users do not have any access to hidden dynamic control bars and are therefore not able, to restore a hidden dynamic control bar and all contained permanent control bars in one step.

It would be a great improvement, if we could give our end users access to hidden hosting dynamic control bars, too.

Actually it is not completely clear what you want to achieve so let us clear out. If you have a control bar with a dialog inside and some other control bar with another dialog inside then it is up to the users whether they want to dock these control bars in a common tab group and then autohide, or leave them floating and so on. This is the general idea of dockable control bars by definition. Please let us know what restrictions are talking about?

I saw the conversation you had with Hans at http://www.prof-uis.com/Forum_View.aspx?CID=40&M=53980&s=CControlBar. So I can see that you are considering adding this feature even though you haven’t yet.

Here’s a thought though. For this idea, I’ll call the control bars made to support floating "dynamic control bars", and I’ll call the control bars that I make in order to set up my GUI "permanent control bars". I only say this because I could be jumbling the names.

I guess, for every permanent control bar, there is potentially the number of permanent control bars / 2 of these special dynamic control bars to be made. If one dynamic control bar houses two permanent control bars, than I would like the dynamic control bar to register itself with the paint manager, I would like it’s name to be the name of the first permanent control bar / the name of the second permanent control bar, so that it might be "Name 1 / Name 2", and lastly I would like the auto-menu to show "Name 1 / Name 2" as a sub menu which gives you three options: "Show / Hide All", "Name 1", "Name 2". The "Show / Hide All" would auto-hide or display the group. In this way, it is clear how to access the dynamic control bar that holds more than one permanent control bar and it is also clear how to get just one permanent control bar. The dynamic control bar should keep the state of its members, so that it can redisplay properly.