Forum

MAYBE THIS WAS POSTED BEFORE BUT I DID NOT SEE IT IN THE FORUM SO I REPOST

Hello

I have a tabbed MDI application. Since I need to control the tab captions myself I derived a class CMyExtTabMdiWnd from CExtTabMdiWnd and implemented CMyExtTabMdiWnd::OnTabWndQueryItemText. I think that leads to my problem that in the "Window" menu only the accelerator numbers "1   ", "2   " are displayed.

There is a screenshot under

http://www.ierax.removeme.ch/download/mdiwindow.jpg

 

(remove "removeme.")

I would like my tab captions to appear in the Window menu. What am I doing wrong?

Thanks

Thomas

 

 

T

CExtTabMdiWnd

We need more details about your project. First of all, whether the CExtMenuControlBar window is enabled for the drag-and-drop-based redocking or not? We also need to know whether the MFC’s document view architecture is used. Finally, if it is possible to let us take a look at your project, then please send it to us. This would let us analyze your UI initialization code and avoid making a guess.

Hello

Thank you for your reply. I can not send you the whole project but I can give you the key sources where the Prof-UIS stuff is in.

Please download from http://www.ierax.removeme.ch/download/veprofuis.zip (please remove "removeme.")

I am NOT using the doc/view architecture of MFC

I guess there is not much to say to CMainFrame. You will find your way around that one.

The constructor of CVEDocument contains the code to create a child frame.

CChildFrame contains the child frame code.

I will gladly answer any questions if you need further information

Thank you

Thomas

You should not use the CFrameWnd::EnableDocking() method with Prof-UIS control bars. Please use the CExtControlBar::FrameEnableDocking() method instead. So, just find the following line in the CMainFrame::OnCreate() method:

EnableDocking(CBRS_ALIGN_ANY);

and replace it with the following code:

if( ! CExtControlBar::FrameEnableDocking(this) )
{
     ASSERT( FALSE );
     return -1;
}

This is the single error we managed to find but it cannot affect the MDI windows list in the popup menu. We tried to reproduce the problem with our MDIDOCVIEW sample application but failed. We would like to ask you to set a breakpoint at the beginning of the CExtPopupMenuWnd::UpdateMdiWindowsMenu() method, run your application and invoke the Window menu in the menu bar when at least one MDI child frame window is open. Please step into the loop inside the CExtPopupMenuWnd::UpdateMdiWindowsMenu() method which has the following for statement:

for( INT nWin = 1; true; nWin++, nCmdID++ )

We wonder how the sWinName local variable is initialized by the following code in this loop?

CString sWinName( _T("") );
CWnd::FromHandle( hWndChildFrame )-> GetWindowText( sWinName );

We guess the window text (caption) of MDI child frames may be empty.

Hello

Thank you for your help. It gets more and more confusing. I noticed that UpdateMdiWindowsMenu was not called at all. So I found out that I had to do several things in order for that method to be called (i.e. SetMdiWindowPopupName). But I noticed that unlike in your MDIDOCVIEW sample there is no second time that the menu is updated (like triggered by _DelayUpdateMenuBar) so I call UpdateMenuBar myself after creation.

Then it hit the method you suggested and the sWinName was empty indeed. So I set the window title after creation of the frame by using SetWindowText.

The strange thing is that I get two menu sections now (see link to screenshot below. Remove "removeme."). Both half filled. If I open the menu a few times and I switch the mdi children then the menu becomes empty again. Somehow the windows become renamed. I spent several hours debugging but I did not find out what is creating my second menu.

Thanks for any help. Thomas.

http://www.ierax.removeme.ch/download/mdiwindow.jpg

We faced the same behavior in the application of one of our customers. It appears only if the menu bar is not enabled for drag-and-drop-based re-docking. Unfortunately we failed to reproduce this bug in any of Prof-UIS samples. That problem has been temporarily solved by handling the CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel registered message and finding the menu item with the AFX_IDM_FIRST_MDICHILD identifier, removing all the items in the range of AFX_IDM_FIRST_MDICHILD .. (AFX_IDM_FIRST_MDICHILD+9) and inserting a single copy of window list commands.

It would be perfect if you would help us find out what’s wrong with the MDI menu. We would appreciate if you send us a "stripped" but fully functional version of your project which demonstrates the bug.

Hello

Your wish is my command ;-) I stripped almost everything to the bones and the problem still persists. The application is crashing upon closing now which is a result of stripping. The real application doesn’t do that so we can safely ignore this crash. Just open a file (it doesn’t matter which in the stripped version) and the documents will open. If there are questions don’t hesitate to ask.

http://www.ierax.removeme.ch/download/veview.zip (remove the "removeme" part)

Thanks in advance

Thomas

We made several improvements in your project to make the MDI windows list menu working as it must. The following files were modified: MainFrm.cpp, MainFrm.h, VEDocument.cpp, VEDocument.h and ChildFrm.cpp. All the changes are marked as follows:

    // BEGIN: ADDED BY PROF-UIS TECH SUPPORT TEAM
CMainFrame * pMainFrame = CMainFrame::GetMainFrame();
    ASSERT_VALID( pMainFrame );
    // END: ADDED BY PROF-UIS TECH SUPPORT TEAM

or

    // BEGIN: CHANGED BY PROF-UIS TECH SUPPORT TEAM
            pMainFrame->m_hMDIMenu, // NULL,
            pMainFrame->m_hMDIAccel // NULL
    // END: CHANGED BY PROF-UIS TECH SUPPORT TEAM

So, just search for the PROF-UIS TECH SUPPORT TEAM text. There were two problems in your project, which were caused by the following errors:

1) The created instances of the CChildFrm window had no assigned MDI menus.

2) These child frames had no assigned frame window titles.

Please download the improved version of your "stripped" project from our site.

Besides we would like to mention that:

1) Your application is the classic MDI application based on the document/view architecture. So, we have no idea why you did not use the standard MFC document/view features and coded it yourself instead.

2) The application still crashes on shutdown, but we guess this is a result of "stripping".

Thank you very much. The stripped program works fine. I have a problem in the real application though. I have changed everything the way you suggested. When I create the MDI menu the toolbar comes up with a failing assertion on line 455 of exttoolcontrolbar.cpp (see below)

Comments:

• I can create the MDI accel and everything works fine. It’s just the MDI menu that causes trouble.


• The toolbar is fine as long as I don’t open a document. Only when I open a document the assertion comes up


• The assertion seems to happen for the very first button. The index of the loop of buttons seems to be 0

You have asked why I am not using MFC doc/view model. I am using a C DLL that has an intrinsic doc/view model which I would have had to map onto the MFC model. Maybe this would have been possible but I decided against it.

Thomas

ASSERT_VALID( pNode );

return CExtSafeString( pNode->GetTextInToolbar( pCmdItem ) );

}

#endif // (!defined __EXT_MFC_NO_CUSTOMIZE)

ASSERT( pCmdItem != NULL ); <===== pCmdItem is NULL

if( !pCmdItem->m_sToolbarText.IsEmpty() )

sText = pCmdItem->m_sToolbarText;

It seems the information about the child window (document) toolbar or menu bar is not included into the command manager. Have you invoked the following methods?

VERIFY(
  g_CmdManager->UpdateFromMenu(
   pApp->m_pszProfileName,
   IDR_YOUR_DOCUMENT
   )
  );
 VERIFY(
  g_CmdManager->UpdateFromToolBar(
   pApp->m_pszProfileName,
   IDR_YOUR_DOCUMENT
   )
  );

Thank you for your suggestion. There is no child window toolbar or menubar. The assertion seems to happen when the main toolbar is searched for ID_FILE_OPEN which is the very first button on the bar. The following things are noteworthy:

• This only happens when a document is opened. Without open document the buttons on the toolbar are working fine.


• Your stripped program which I downloaded worked fine. The non-stripped version has the same toolbar and more or less the same MDI stuff your version had.


• Your stripped version worked fine even with a document open

Can I provide you with more information? What could be another reason for this to happen?

Thanks in advance

Thomas

If the stripped version of your application works, then the full version must also work. We may review parts of your code (from the full version) but to fix the code remotely (connecting to your desktop) would be much easier and faster. If the latter is appropriate to you, please contact us by e-mail.

Hello

Thank you for your offer to remotely debug the problem. I sent you an e-mail but I think I never got a reply or I overlooked it within my spam.

My suggestion would be to start the session any day this week starting at 10am EST = 4pm CET if this would be convenient for you.

I can even provide a very easy remote desktop program (200kb without install) which goes via an outside server so we won’t have any firewall problems. You can download the client from http://www.deskshare.net/en/support/startclient.aspx. To connect to us you will need a pin code which is valid for two minutes and which I will have to provide. I think if we do this we might also need an instant messenger. I am using Yahoo but I am flexible to install something else.

We are using Windows 2000 that has no built in remote desktop capability.

What do you think? What are your suggestions?

Thanks

Thomas

 

Alex and Sergey

Thank you very much for your support (today and always). We got disconnected but being a Prof-UIS detective I found out that there is another message g_nMsgPrepareMenu that gets sent. So I could finish Sergey’s work and implement the recent file list the way he suggested.

All the best

Thomas

 

The disconnection was caused by technical problems. We are really sorry for that. We are ready to proceed and resolve all the issues left unresolved.

The main things are solved. There are only two questions remaining:

• In the "Windows" menu there remains a useless separator at the bottom of the menu in case there are no open documents. Is there an easy way to remove this or should I use g_nMsgPrepareMenu for this too?


• When I am building the "recently used" file list with ItemInsertCommand: How can I add a text for the status bar (the equivalent to m_sTipStatus in CExtCmdItem)?

Thanks again for your always very good help

Thomas

The popup menu window does not add a useless separator to the bottom of the Windows menu. Please check the menu resources for separators near the bottom of the menu sublevel. The CExtPopupMenuWnd::ItemInsertCommand() method inserts a menu command item which is not based on the CExtCmdItem command description object in the command manager. So, it is not possible to set up the status tip for such menu items. You can switch to using the CExtPopupMenuWnd::ItemInsert() method and allocate a required number of MRU commands during the app startup. So, you will be able to access each command description and assign the CExtCmdItem::m_sTipStatus text.