Cross-Merge Toolbars

There seems to be some issues with MDI Children cross-merging with each others menus. Typically you would want your Child''s bars to merge with your Parent''s bars. What you don''t normally want is Child A to merge with Child B (only 1 child is ever active and as such only 1 menu would be shown in the first place). What I''ve got going on here is Child A merging with Child B. It does hide the inactive child''s bar items correctly. But because it is still merging them internally, the order of the controls on common-named toolbars gets really messed up. And if you go to customize the bar, it shows the inactive child''s bar items. It also shows all inactive MDI child bars as available bars. We''d like to see an option to not merge child frame managers or at least tell a bar to never merge. Thanks, -Marc

Hi Marc Thanks for the feedback. The Essential Tools team will take a look at your suggestion and we will update this posting as soon as we have more information. Regards Arun

Is there a way I could work around this issue? Any suggestions would be greatly appreciated.

One other issue is that because the other child toolbars are only hidden, they still take up space on the toolbar. So if Child A has a toolbar that covers 1/2 the toobar area, when Child B activates the toolbar is placed 1/2 way down the toolbar. It looks rather silly to the end user.

Hi Marc The responses to your questions are inline: What I''''ve got going on here is Child A merging with Child B. It does hide the inactive child''''s bar items correctly. But because it is still merging them internally, the order of the controls on common-named toolbars gets really messed up. -The order in which the merged items are shown can be controled by the BarItem.MergeOrder property. It also shows all inactive MDI child bars as available bars. -This is by design. We wanted it to work the way VS.Net works. For example, when the code-editor is active in VS.Net, the toolbars'' context-menu still shows the "Design" toolbar (basically all the toolbars are available all the time). And if you go to customize the bar, it shows the inactive child''''s bar items. -This is again how we designed our merged bar. We do not want to show the inactive items normally, but during customizing we want to show the items so that the user can clearly determine the position of a drop, while adding a new item to a merged bar. We''''d like to see an option to not merge child frame managers or at least tell a bar to never merge. -Bars will not merge if they have different BarNames. If you do want to have similar BarNames (this does go against windows UI standard) we will make it a feature request. One other issue is that because the other child toolbars are only hidden, they still take up space on the toolbar. So if Child A has a toolbar that covers 1/2 the toobar area, when Child B activates the toolbar is placed 1/2 way down the toolbar. -Can you give us more information, send us steps to reproduce this issue in one of the Tools samples, or send us a sample via Direct Trac Regards Arun

I understand that MergeOrder will control this, but we are talking about a very large number of windows here. It would take a massive effort to keep track of what goes where. This method just doesn''t scale well with a virtual ton of windows. As for working like VS.NET, that is understandable. However, I would suggest this is in fact not how it is working. In Visual Studio you have every toolbar all the time. With your control you only have those toolbars when a window with those bars is open someplace (even if it is hidden). If I needed a VS.NET style UI I would have a single bar manager on the main window and use events to talk to the child windows. Either way, the VS.NET model only works if you are dealing with a VS.NET style application. When you are building a QuickBooks or other such database driven application it doesn''t work so well. In these applications the MDI format is used for keeping the application self-contained not for managing documents. Having the A/R toolbar there when they are working on a Purchase Order just isn''t logical. I really need some way to solve this one. We simply cannot ship an application in this state. And the last thing we need right now it to delay our project with replacing the menu/toolbar package.

One possible solution for us would be having a "Merge Type" on the Toolbar object. That way I could just tell the toolbar to "Replace" any other toolbar with the same name with itself.

Marc, Regarding VS.Net style behavior: We in fact support true VS.Net style behavior where the toolbars of all the potential child forms are "available" all the time. This is achieved through a call to the RegisterMDIChildTypes method of the MainFrameBarManager. Our XPMEnusMDI sample illustrates this. Regarding preventing the child toolbars merge: So, I suppose you do want to give these toolbars the same BarName? (As we mentioned earlier, giving them different BarNames will automatically prevent the merge). If so, I will try to find out if there is an easy workaround or a quick-fix we could apply in our next verison. Regards, Praveen

The problem is that if we use different names then every toolbar will show up when you right-click. We only want the current child''s toolbars to show up there. We also only want the toolbar items for the child and the main window to show up in the customize screen. And when we use different toolbar names the placement is off when they are displayed. In other words, if Child A has a toolbar 100 pixels wide then the left edge of Child B''s toolbar will be placed 100 pixels into the window. But because Child A''s toolbar is hidden, that leaves a 100 pixels of empty toolbar to the right of the control. And this effect gets worse when you consider all the windows we have to deal with. For example, if every window had 100 pixel toolbars then the 50th window would put the left edge of it''s toolbar at the 5,000 pixel position. Needless to say this creates problems when you have an application with over 100 windows. :) So what we really need/want is the ability to have the MainFrameBarManage only include the bars for itself and the active child''s ChildFrameBarManager.

Marc, Development is researching on whether your following request can be quickly supported before our final 2.0 release. "So what we really need/want is the ability to have the MainFrameBarManage only include the bars for itself and the active child''''s ChildFrameBarManager." This is pretty late in our beta cycle to add new features, but we are treating this as an exception. We will keep you updated. Regards, Praveen Ramesh

Thank you very much. It would really save my butt over here.

Are there any update on this issue?

Hi Marc We now have added support in XPMenus for merging the menus of the active child form alone. This feature will be available in the next version(the current version available is 2.0.2.1). We hope to get a Release Candidate out next week. Watch the forums and the Support page for more details/announcements. Kindly open an incident using Direct-Trac after the Release Candidate becomes available. Regards Arun

You guys rock.

Could you point me to where this feature is located/called in 2.0.3.0? I can''t seem to find it anywhere.

Hi Marc, Please refer to the modified version of the XPMenusMDI_sample attached here which shows how this can be accomplished. Kindly note the code in the Activated and Deactivate event handlers of the of the TextEditorForm and the ImageEditorForm. Also note that the Deactivate event exists only in .NET v1.1. Please take a look at my sample above and let me know if this meets your requirements. Thanks for considering Syncfusion products. Regards, Guru Patwal Syncfusion, Inc.

Look good to me! Thanks a lot guys, this really makes my life a lot easier.

Hi Marc, Thanks for the update. We appreciate your continued interest in Syncfusion products. Regards, Guru Patwal SYncfusion, Inc.