Hi Yiannis,

I've read the tutorial as well. To me it focuses on the case where MDI Frame owns the menu and application object uses ToolbarSheetTitle = ToolbarFrameTitle. Many apps are written like that. Many are not - and of these several have quite complex menu differences similar to replacing many ribbon items.

UI/UX Design
I guess we miss collective experience in best practices for ribbons in (large, complex) user-interfaces.
Programming language is not the issue to me.
Instead, it is the interaction design or rather user's experience.

Yesterday I wrote an intro-level article on How to Define Events for RibbonBar Controls.
Your request for recommendation is certainly at another level.
Maybe someone else in the community has more experience designing and implementing ribbon UIs? 

Performance Impact
Also, I haven't looked at cost of switching ribbon content in-flight. Especially back-and-forth.
Say user switches back and forth between two sheets using different ribbon; what is the delay in msec of loading a new ribbon (incl. destroy old ribbon) when it holds 200 items?
What is cost of dynamically showing/hiding individual items instead, when say approx 10% of items differ from one sheet to another?

New UI interaction paradigm = new learning needs.

HTH /Michael

Hi Yiannis,

Yes. The tutorial is an example that shows you how to add a RibbonBar control in a MDI window and how to design the RibbonBar. The way to add a RibbonBar control in a main window is quite similar:

1) Please just look at RibbonBar control as a normal control type. You can directly place a RibbonBar control in the window, and then use the Visible/Enable property to control the display of the control. 

2) With the RibbonBar Builder you create the actual RibbonBar XML file (one or multiple).  You can load the same RibbonBar XML file into the RibbonBar control of one or multiple main windows.

3) Using the RibbonBar control properties/events/functions (see https://docs.appeon.com/appeon_online_help/pb2019r2/objects_and_controls/ch02s90.html), you shall be able to control the display of the RibbonBar in each window.

Best regards, Julie

Hi Yianis;

   That is a very good question around the use of the RibbonBar in a full MDI type application. Personally, I have not seen any full MDI App from any development tool use a ribbon bar. You can even see this when MS-Office (a long time) ago was full MDI. Once MS started using the RibbonBar approach in their MS-Office design, they then went to an SDI (Single Document Interface) - which we still see today in MS-Office 365.

   Menus are the still the best way to handle multiple documents (business transaction) open at any given time. The automatic switch to a related Menu and even toolbar subset easily gives your App the proper control over a complex process flow. Trying to emulate that in a full MDI application (or MDMI - Mutiple Document Multiple Interface for that matter) could be a coding nightmare with swapping the ribbon control in and out all the time on any change of sheet focus. Then add to that the complexity of dynamic language swapping and - Eeeeeek!  ;-)

Just my $0.02.

Regards ... Chris

If the sheets in your MDI use drastically different menu's, you'll probably have to do the same with the Ribbon (create drastically different ribbons and replace them on Activate and Close). The other approach would be to do an inventory of all your menu's and determine how much overlap there is. You could have ribbon items that are disabled until a window opens that uses it, then enable it.

For comparison, the Ribbon in Ultimate Suite renders based on the PB Menu specified and can be re-rendered when a new sheet menu is loaded. This is technically the same approach as creating multiple ribbons and replacing them when needed.

The other option is to create a generic Ribbon that covers most of your applications functionality then move sheet specific items into the sheet itself (using a toolbar for example).

Supplement to Brad's reply

Example here compares ribbon bar buttons to legacy MenuItems:

NOTES:

• Groups define line breaks between buttons.
• You can show/hide or enable/disable either per item/button, per group, per panel, or per category.
  Properties = Visible and Enabled.
• Ribbon control assigns ItemHandle numeric-ID at runtime (like in TreeView/ListView).
  At design time you need to use Tag as a text-ID so code can
  1. Obtain the item in its current state using GetItemByHandle;
  2. Change its state by changing properties or calling functions;
  3. Update ribbon dynamically using SetItem.
• PowerTipText + PowerTipDescription is ribbon item's equivalence of menu item's ToolTip.
  • "Text" is PowerTip's title.
  • "Description" PowerTip's body
  • Title includes Shortcut key when it is defined.
• Both buttons define a user event to trigger when button is Clicked but leaves Selected event empty (just like most menu items do)
  
  • Menu: Each MenuItem has its own Clicked script and Selected script.
  • Ribbon: Each button defines which user event on the RibbonBar control to call.
    Multiple button can trigger same event. Events therefore have handle parameter to identify which button was clicked/selected.
  • Choose user event name wisely so they indicate purpose of that event.
    HERE in example: "ue_Clicked" as user event for Close All buttons seems very unwise.
    Better event names are "ue_CloseCurrent" and "ue_CloseAll".

I plan to have a ribbon bar, that will contain the application menu (In one or more Categories) and a Category that will contain the operations of each specific sheet.

 Each sheet, when it becomes active, will paint only the operations bar. One idea could be to paint the operation category when the window is open, then when the sheet is deactivated, I can use the ExportToXML(), store it in memory and use LoadStringFromXML() when the sheet is activated.

I am afraid of the size of our menu and the possible lagging of the application, each time the user opens a new or changes the active sheet, that’s why I asked for recommendations about it.

What do you think about that?

Thanks....