1. Yiannis Papadomichelakis
  2. Beta Testing
  3. Monday, 20 January 2020 16:33 PM UTC

I read the “How to Replace an Application Menu with a RibbonBar” and I have some questions that I would like to discuss with you.

This tutorial, replaces the MDI menu, with the Ribbon bar. In an existing MDI application, each main window has its own menu, with its own functionality. I think that this topic is not covered from the tutorial, and it very important.

 Let’s suppose that I transfer the application’s menu to the ribbonbar. What do you think it’s the recommended approach for the main window functionality? Shall I have something like a controller that will automatically replace the operation Category, every time a main window becomes active?

What do you think? What’s the proper approach for this problem?


Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 21 January 2020 15:34 PM UTC
  2. Beta Testing
  3. # 1

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

  1. Michael Kramer
  2. Tuesday, 21 January 2020 16:06 PM UTC
My counter example is Visual Studio where ribbon-bar replaced the toolbar - everything else centers around tabbed-MDI with traditional menu - albeit a very complex UI incl. menu in title-bar and dynamic, dockable panels.

Actually, any "modern" IDE I can think of has similar tabbed-MDI + panels.

Office apps on the other hand moved to multi-SDI + ribbon + panels + (neither menu-bar nor toolbar).

Transforming from MDI into new Multi-SDI paradigm is major effort. So much navigation needs redesign. On the other hand, simply replacing toolbar with ribbon-bar; then gradually extend the ribbon-bar content seems to me much less of a challenge.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Wednesday, 22 January 2020 16:12 PM UTC
The key point I see in your observation of VS (or any ribbon based app) is the "Dockable" panels feature. Unfortunately, Appeon PB no longer supports the "Dockable Window" feature. This would have been the "cats meow" for supporting the dockable panel equivalent. That's one of the places where Brad Wery's implementation is superior.
  1. Helpful
There are no comments made yet.
Brad Wery Accepted Answer Pending Moderation
  1. Tuesday, 21 January 2020 16:20 PM UTC
  2. Beta Testing
  3. # 2

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).

  1. Chris Pollach @Appeon
  2. Wednesday, 22 January 2020 17:39 PM UTC
Hi Brad;

Your use of a PB Menu that drives a related ribbonbar (that can also be inherited and encapsulated) is an ingenious approach!

Regards ... Chris
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Tuesday, 21 January 2020 18:50 PM UTC
  2. Beta Testing
  3. # 3

Supplement to Brad's reply

Example here compares ribbon bar buttons to legacy MenuItems:


  • 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.
  • PowerTipTextPowerTipDescription 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".
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Monday, 20 January 2020 22:20 PM UTC
  2. Beta Testing
  3. # 4

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

There are no comments made yet.
Julie Jiang @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 21 January 2020 05:41 AM UTC
  2. Beta Testing
  3. # 5

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


  1. Yiannis Papadomichelakis
  2. Tuesday, 21 January 2020 09:46 AM UTC
Hi Julie

I would like to replace the traditional menu with the ribbon bar, because it looks fresh and will give a modern feel to our ERP application. The frame menu of our application contains hundreds of menu items that open edit and report windows.

If the ribbon contains the application menu, then it should be placed on the MDI window. If I place ribbon bars on each sheet (because each of these has it’s own functionality) then I will end up having 2 visible ribbons.

The tutorial’s idea of having a ribbon bar in the MDI frame is very nice and I was looking for a suggestion around that concept.

  1. Helpful
  1. Julie Jiang @Appeon
  2. Wednesday, 22 January 2020 01:54 AM UTC
Hi Yiannis,

Supplement to Brad and Michael's reply:

We understand that you would prefer not having 2 visible ribbons, and each of the sheets shall have its own functionality set. For this case, you may define different RibbonBar XML files for different sheets, and dynamically switch the RibbonBar XML to load in the MDI window for each sheet.

For example, consider to:

1) Define a base RibbonBar XML (XML01) that contains the common functionality set shared by all sheets;

2) For sheet A, create XML02 that contains XML01 and additional items specific to sheet A;

3) For sheet B, create XML03 that contains XML01 and additional items specific to sheet B;

4) Add conditions in the MDI window event to load diffferent RibbonBar XML (XML01, XML02, or XML03) depending on the currently-open sheet window.

Best regards, Julie
  1. Helpful
There are no comments made yet.
Yiannis Papadomichelakis Accepted Answer Pending Moderation
  1. Wednesday, 22 January 2020 15:32 PM UTC
  2. Beta Testing
  3. # 6

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?


  1. Michael Kramer
  2. Wednesday, 22 January 2020 15:55 PM UTC
Performance I'm not sure. All I can say for sure is that full LoadFromXML is markedly slower than show/hide single category.

You could potentially have several categories and panels within the ribbon that you show/hide on demand instead of constructing the full ribbon from ground up.
  1. Helpful
  1. Yiannis Papadomichelakis
  2. Wednesday, 22 January 2020 16:07 PM UTC
Wouldn't be nice if LoadFromXML() could paint only part of the Ribbon and not all of it? ?
  1. Helpful
There are no comments made yet.
  • Page :
  • 1

There are no replies made for this question yet.
However, you are not allowed to reply to this question.