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 » How to dock CExtControlBar in and out of MDI Client Collapse All
Subject Author Date
Dave Kymlicka Feb 24, 2005 - 12:31 AM

In considering using Prof UIS (converting from another MFC framework), I would have to preserve some existing behaviour that allows clients to decide where they want CExtControlBar(s) located, at anytime:
-floating
-docked in mainframe
-docked in MDI Client
Moving in/out of MDI Client is a menu-driven option, no drag-n-drop required.


Using your demo "MDI_InnerOuterBars" as an example, what I’m trying to accomplish
would be the equivalent of putting both of the following in MDI Client area:
CExtToolControlBar m_wndToolbar0;
CChildView m_wndView;


Your Forum answers to: "Questions about dockable control bars.  Ken Knapton Nov 30, 2004" comes very close to what I’m after, but replacing MDI Client with CExtTabPageContainerFlatWnd seems a bit much for our needs.


Is there a simple way to make CExtControlBar behave similar to other views while in MDI Client (tile windows/restore/min/maximized, and showing tabs)?


Your assistance is greatly appreciated.

Technical Support Feb 24, 2005 - 10:41 AM

It seems we have some misunderstanding of what you need. The CExtControlBar window, by definition, is not similar to the MDI child window, nor to the main frame window. Besides, we wonder what is the reason for moving a resizable control bar between the child frame and the main frame. Typically a resizable control bar in the MDI child frame contains some information relating to the contents of its view window. If a resizable control bar is in the main frame window, then it contains info relating to all views or, to the active one only. It seems we additionally need to discuss the design of your application.

Dave Kymlicka Feb 24, 2005 - 12:22 PM

Sorry, I’ll try to clarify as best as I can.
I’d like to take a ControlBar, put it into the MDI Client area and have it behave (visually) the same as other views in there as well.


By example, in your ProfStudio demo, create 2 new docs using Ctrl + N.
As a result, I have 2 new CChildView (inside a CProfStudioThinFrame?) that are children of MDI Client, and 2 tabs (labelled "ProfStudio child window") at the top of MDI Client area that allows me to switch between them.
Now pretend we’re in VC++ 6.0, and I ALSO want to put my "Workspace" ControlBar into the MDI Client.  This is done via "Window --> Docking View [Alt +F6]".


This is the functionality I’m looking for. VC++ doesn’t put tabs at top of MDI Client, but imagine that it did: we would now see 3 tabs: "ProfStudio child window" / "ProfStudio child window" / "Workspace".
As with VC++, I would also need to undo the "Docking view", to return the ControlBar back to MainFrame, and have it resume normal control bar behaviour.


I see that VS .NET doesn’t use this concept anymore, but I must support it in our app. Is this a bit better explanation?

Technical Support Feb 25, 2005 - 3:10 AM

Thank you for clarifying your question. What you need in your project is not supported in Prof-UIS explicitly but nevertheless can be done. This task is very specific for a particular project. It depends on whether the project is based in the document/view architecture, whether Prof-UIS customize features are used, and some other factors.

We will outline below some guidelines on what you should pay attention to. First of all, you will obviously have to deal with UI that supports a dynamic number of resizable control bars. Each control bar inside a frame window has its own unique dialog control identifier and is associated with the show/hide command with the same identifier. The g_CmdManager()->CmdAllocPtr() API can be used for generating unique identifiers for dynamic bars. Then you need to keep information about all the dynamic bars and their child windows somewhere. This information should be saved (serialized) in the CMainFrame::DestroyWindow() method as it is done for all other control bars. This information should be loaded in the CMainFrame::OnCreate() method and used for creating these dynamic control bars and their child windows and, what is the most important, all these dynamic control bars need be created before restoring control bars’ states. Besides, the information about each resizable bar should include a flag indicating whether it is restored as a CExtControlBar instance or as a CMDIChildWnd instance. Moreover, you will need to handle non-client window area messages of resizable control bars and MDI child frames to implement context menus that allows you to switch between window states (dockable control bar/MDI child window).

We understand this task may be a bit complicated but we are sure that it can be done step by step. If you start working on this, you can count on our help.

Dave Kymlicka Feb 28, 2005 - 6:29 PM

Wow, you’re thorough.
Fact is, since we’re migrating from Stingray, we’ve dealt with most (but not all) of this stuff.
Our problem now is the docking CExtControlBar into a CMDIChildWnd, since every MFC extension lib does this a little differently.
Your lib is really good, but missing the one method we need right now, something such as:

void CMainFrame::FloatControlBarInMDIChild(CControlBar* pBar)
{
   CChildFrame* pFrame = this->CreateNewChild(RUNTIME_CLASS(CChildFrame), IDR_MDITYPE);
 pBar->EnableDocking(CBRS_ALIGN_ANY);
 pFrame->DockControlBar(pBar, AFX_IDW_DOCKBAR_TOP);
}



So, to get used to your way of doing things, I’m been experimenting with your sample project "MDI_InnerOuterBars", as it already has docked ControlBars into MDI Client, but I’m still having problems.
Inside CChildFrame, I’ve removed all views and CExtWFF, and all CExtControlBar except m_wndResizableBar0.


In CChildFrame::OnCreate()
{
 m_wndResizableBar0.Create(_T("ResizeBar 0"), this, ID_VIEW_CHILDFRAME_BAR_0, FWS_ADDTOTITLE);
 m_wndResizableBar0.EnableDocking(CBRS_ALIGN_ANY);
 m_wndResizableBar0.DockControlBar( AFX_IDW_DOCKBAR_TOP, 1 );
}


-can’t get CExtControlBar to take up all space in new CChildFrame (have tried dwStyle |= FWS_SNAPTOBARS).
-can’t get repainting right (have tried styles WS_CLIPCHILDREN, wS_CLIPSIBLINGS), appears due to fact that ControlBar doesn’t take up all the frame

Stuff that is working OK:
-MDI tabs (I even get to choose: CExtTabMdiWnd, CExtTabMdiWhidbeyWnd, etc... NICE!)
-moving window around inside MDI (except repaint issue above)


SO that’s my first step, would appreciate any advice you can offer.


If you can think of easy way to implement FloatControlBarInMDIChild(), that would be even better!

Technical Support Mar 1, 2005 - 8:01 AM

We may guess that you have removed or commented something that should be left intact in your modified version of MDI_InnerOuterBars sample application. So, it would be helpful to take a look at the current version of this project. We believe it’s possible to get it work again. Unfortunately, there is not enough information in your message to come to any conclusion about what has been broken.

We cannot get two ideas:

  • What is the reason to make a resizable control bar occupy the entire area of the MDI child frame and what is the role of invisible view window in this case?
  • In which way should the user access the resizable control bar that is floating inside the MDI child frame as a window with the WS_CHILD style if the control bar is somewhere behind the right or bottom margin of the frame?

Dave Kymlicka Mar 28, 2005 - 8:23 PM

So that others may benefit from this thread, here’s a summary of what has happened as of today.

We’re trying to emulate the same behaviour as Visual Studio C++ 6.0, when it "docks" a ControlBar as an MDI-child.
See ’Docking View’ [Alt + F6] to demonstrate the behaviour.

Prof-UIS v2.31 introduces the CExtDynamicControlBar class, which implements this behaviour, and resolves my issue.

Nice work!