Forum

Hi!
I am writing an MDI app using CExtTabMdiWhidbeyWnd
I just face 3 problems (one bigger than the others):

- Why the size of the document is not stored? for instance, if I open a new MDI doc, maximize it, close it, then open another new document, the new one will appear windowed and not maximized.
is there anything I can do, or do I have to implement this "memory" mechanics by myself?

- when I open many document and maximize them, and when I use the tabs to switch from one to another, I can see clearly the "soon to be the active doc" in a windowed state before it is displayed as maximized. Of course, it’s short, but it is really bothering. (this is my bigger problem)

- is there an automated way to hide the tabs when the MDI docs are displayed in a windowed mode?

Actually, I could solve the first and the third problem by myself, but i am quite stucked by the 2nd.

Best regards,

Raph

We do not save/restore the window placement for MDI child frames because we have no enough information to identify each MDI child frame window. In fact, only your application knows how to distinct one open MDI child frame from another. Each child frame may be identified by some unique information specific for your document object and by its corresponding view window. So Prof-UIS does not simply know what each MDI child frame is? For instance, each control bar (toolbar, resizable bar, status bar and etc) can be identified with the dialog control identifier of the control bar window. This dialog control identifier is unique for each bar and that is why we can use it as command identifier in the menu for switching its visibility. We are using this identifier when saving/restoring control bar states. But an MDI child frame has nothing unique to be identified with. Besides only your application knows how to create MDI child frames and correctly open and attach the document and the view to it. Finally there are MDI applications without document/view architecture. In this case we know nothing about MDI child frames but their window handles at run time. We did some search and found the following article with this: http://www.codeproject.com/docview/persistframes.asp.

The flicker effect is a well known bug of Windows MDI interface on Windows XP or later OS version. You can see this bug in any MDI application running on Windows XP: Visual C++ 6.0 IDE and Visual Studio .NET/2005 IDE configured to use the standard MDI interface instead of their written from scratch tabbed interfaces. Prof-UIS 2.54 fixes this bug automatically if you are using the CExtMenuControlBar instead of the standard menu line in the MDI main frame window.

You can fully control the visibility of the MDI tab control. Just override the CExtTabWnd::OnTabWndSyncVisibility() virtual method and simply show or hide the tab window depending on your conditions. The default method’s implementation hides the MDI tab window if there are no MDI child frames present. The ProfStudio sample application implements the custom MDI tab control for emulating tabbed and MDI classic interfaces switchable on-the-fly dependently on user preferences.