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 Tech Support » 2.82 and mdi window open doc listing problem Collapse All
Subject Author Date
Timothy Anderson Sep 16, 2008 - 6:10 PM

We jumped to 2k5 and to 2.82. Somewhere in the jump the automatic updating of the list of open documents in the top level "window" command stopped working correctly, it simply doesn’t show the open documents any longer.


I was trying to avoid jumping to 2.84 since we are extremely close to releasing, and your example apps appear to work OK. Where should I start poking around to try to track this down?


There appears to be a newer way of deriving off of the CMDIFrame class, I’ll poke my head in there first.

Timothy Anderson Sep 17, 2008 - 5:15 PM

...or possibly dig through the MenuInfo after SetButtons is called...

Timothy Anderson Sep 17, 2008 - 12:32 PM

Ya, I’m doing that. My example works like the mdidocview one. Switching the class derivation didn’t seem to help.


One other thing, I did add in the profauto stuff around the same time so there may be some fighting between profauto and the main application. I’ll see if I can backtrack this out to find out if that’s the problem.

Technical Support Sep 17, 2008 - 5:54 AM

The list of open MDI child frame windows works equally in all MFC versions. If you haven’t changed any UI related code, this feature should work in your project. The list of open MDI child frame windows appears in the Window menu because the menu bar’s button with "Windows" text is marked for displaying this list of commands by invoking the menu bar’s SetMdiWindowPopupName() method. So, first of all, please ensure this method is invoked in your project somewhere near menu bar creation code.

Timothy Anderson Sep 17, 2008 - 12:47 PM

It’s profauto. Once profauto was removed everything started working again. I’ll keep going in this direction.


This may also be why the "delete" key no longer works in the main app window also.

Timothy Anderson Sep 17, 2008 - 2:27 PM

I’ve tracked this a little futher.


On menu creation, a normal MDI application doesn’t have a MenuInfo pointer on the initial timer fired menu build up in CExtMenuControlBar::_UpdateMenuBar. Since this is the case, it plows through all of the new buildup of the menu inside the CExtMenuControlBar::_UpdateMenuBar code. This adds in all the extra "Window" information as appropriate.


For a customized site, this menu command is already hanging around so it’s never built inside this call.


So the question is how do I update the customized site’s MenuInfo AFTER I’ve added in the menus for all of my MDI child windows in order to update their own internal "buttons" so this displays correctly? Is there a better way to approach this?

Timothy Anderson Sep 17, 2008 - 5:13 PM


 



It looks like CExtToolControlBar::SetButtons should probably dig through the buttons as it is putting them in looking for m_sMdiWindowPopupName, then calling MarkButtonAsMdiWindowsMenu when appropriate? I think I’m playing fast and loose with the variables used, and there is probably an easier way to do this.


I was going to probably setup a OnExtMenuPrepare handler similarly to the mdidocview example and unfortunately duplicate some of the work done by the toolkit for setting up in there.

It looks like you need to do some extra hand standing with m_sMdiWindowPopupName in order to properly work with foreign languages.


Timothy Anderson Sep 17, 2008 - 5:16 PM

oops, or possibly dig through the menu info after setbuttons is called inside _UpdateMenuBar

Technical Support Sep 18, 2008 - 12:17 PM

The CExtMenuControlBar::SetMdiWindowPopupName() method is designed for a non-customizable menu bar only. In the case of a customizable menu bar with or without the ProfAuto library the __ECTN_TBB_APPEND_MDI_MENU style should be applied to appropriate command nodes which represent menu bar’s buttons both in active and default command trees of the menu line. The IExtAutoToolButton::AppendMdiMenu() property in the ProfAuto library simply works with this style to a command node. Please find the __ECTN_TBB_APPEND_MDI_MENU text in the source code of the DRAWCLI sample application so you will see how to set it correctly and where.

Timothy Anderson Sep 18, 2008 - 5:58 PM

Sweet. Worked like a champ!