Forum

I tried converting one of my applications over to use CExtMenuControlBar. Unfortunately, I’m getting some strange behavior with it.

The application is an MDI doc/view. (With multi-document templates)

First, the menu bar does not properly redraw between different document types. (It’s as if it’s missing the invalidate when switching document types)

Second, the menu bar does not span across the screen like it does in ProfStudio, FunnyBar demos, etc. Meaning, the light gray area only takes up the portion of the bar that’s actually used instead using the complete width of the main frame.

Third, if I try to undock the bar with click and drag on gripper, an ASSERT fails in objcore.cpp, line 63. AfxStaticDownCast() It looks like it fails because the object type is CDockBar instead of CExtDocOuterBar. CExtControlBar does a STATIC_DOWNCAST in CExtControlBar::InternalDraggingState_t::_DoFixed_BasicAdjustment

I tried creating a simple MDI application, and everything works fine. So there must be something I doing wrong, or some kind of special handling that my app does that confuses Prof-UIS.

I’m trying to figure this out and hope someone might know what I’m doing wrong and point me in the right direction. I’ve created the menu according to FunnyBars demo. (Nothing special; just a simple create, EnableDocking, DockControlBar, and the handler for PreTranslateMessage)

Any help appreciated. Thank you. Kind regards,
Logan

Dear Logan,

To help you we need to take a look at the following source code:

• MainFrm.h and MainFrm.cpp files


• CYourApp::InitInstance() method


• names of the base classes for all documents and views

The complete project’s source code would be more convenient for us.

Just an FYI: using CExtControlBar::FrameEnableDocking fixed the second and third problem that I mentioned in my first post.

Is Prof-UIS framework capable of working hand-in-hand with a mix of regular MFC control bars and Prof-UIS bars, or am I required to convert all of my control bars over to use Prof-UIS based control bars?

Right now, there does not seem to be a way. I will get an ASSERT if I DockControlBar with regular MFC control bars after FrameEnableDocking is called. If I call DockControlBar before the FrameEnableDocking--just for regular MFC bars--they disappear.

Dear Logan,

In Prof-UIS 2.21 we announced Persistent Affixment Algorithm for the fixed-size control bars (toolbars and panel bars). This algorithm enables Prof-UIS control bars to behave similar to the command bars appeared in the latest Microsoft products (Office 2003 and Visual Studio .NET). That requires keeping additional affixment data for each fixed-size bar. So, starting with version 2.21, Prof-UIS is compatible with any standard CControlBar that is not enabled to be dockable by invoking CFrameWnd::EnableDocking() (e.g., the status bar or a non-dockable toolbar).

You can use CExtToolControlBar to replace any kind of CToolBar. The CExtPanelControlBar class is appropriate for replacing any kind of the dialog bar (please take a look at the FixedSizePanels). Any other bar including a splitter window emulator can be implemented with CExtControlBar, which may be either in a fixed mode (e.g., MS Office Task Pane) or in a resizable mode (e.g., the VS .NET dockable pane). In any case, you can remove the caption, modify the buttons, disable a floating state, and whatsoever you want.

Please don’t worry about fixing my problem. I guess what I really want to know is how one is supposed to install Prof-UIS in an existing application. If you have documentation already, please let me know and I will read it.

The Prof-UIS AppWizard is nice and easy to use, and therefore makes Prof-UIS ideal when creating new applications, but for an existing application, it isn’t clear what functions I am required to call to initialize your framework. Or what Prof-UIS expects to see. (For example, I see you call ActivateFrame() in InitInstance instead of ShowWindow(), but I’m not sure why you do it that way)

Initially, I was under the impression that using Prof-UIS menus was as simple as changing CMenu to CExtMenuControlBar. Is this true? Am I required to call CExtControlBar::FrameEnableDocking. If I call these, all my non-Prof-UIS control bars cause ASSERT errors. If I remove the FrameEnableDocking() call, the menus work, but with the problems I described above.

Thank you for your help.

Dear Logan,

Prof-UIS really requires CExtControlBar::FrameEnableDocking() to be invoked instead of CFrameWnd::EnableDocking(). You can read about this in the Docking Mechanism Explained article.

The CFrameWnd::ActivateFrame() method overriding is not needed. But it is convenient to use it for restoring position of the frame window. In all the Prof-UIS samples ActivateFrame() used to set loaded window postion when it invoked first time.

I probably should have taken a closer look at the docking mechanism article beforehand as it has more information than I initially thought.

At this point my application is working great without any functional problems. (Only some minor graphical issues)

I’m pleased with the framework overall. (Especially the examples) It would be great (for new users of Prof-UIS) if the naming conventions were more MFC-like, (i.e. GetItemRect() instead of ItemGet()->ItemRectGet()) but everything is consistent and it is probably too late to change that now anyway. :-)

Thank you for the information.

Dear Logan,

Prof-UIS uses "inverted" naming convention for the class methods. This allows to navigate methods and classes easier in the Visual Studio classes tree.