Dynamics GP Developer Insights: Web Client Window Ribbon - Part 1

Rushi Patel - Click for blog homepageHey, I am Rushi Patel. I am a software developer working on the Microsoft Dynamics GP team in Fargo the last 3 years. I like to spend my time with my family, watching movies and cricket.

At Microsoft, I have worked on Office Accounting and Dynamics GP Workflow prior to my current project – the GP web client. I mostly worked on the UI features of web client before I started working on the Window Ribbon feature. Window Ribbons, as the name implies, appears to be a purely UI concept. That’s true, however there are many dependencies to make Window Ribbons render on web client such as sanScript code and Dexterity support/enhancements that will be explained in depth in this series of articles. 

Note: Click on the images for larger versions.


Introduction

Are most of you aware that the Dynamics GP desktop client already has a Ribbon rendered on its list pages?

The web client will have a similar Ribbon with the same features rendered on its window. All non-modal windows by default will have a Window Ribbon displayed when they are rendered in Dynamics GP web client.

Default Ribbon Rule

There are hundreds of windows that require a Window Ribbon on the Dynamics GP web client. Instead of creating a Window Ribbon definition for each of those windows separately (which is not only time consuming but also a maintenance challenge), we designed a set of  default Window Ribbon rules that will be applied to each window that requires a Window Ribbon on the Dynamics GP web client. Here are some of those rules:

Rule 1: Ribbon Groups

A Window Ribbon must have predefined groups in the following order and Window Ribbon groups will be displayed only if items exist for that group.

  • Actions
  • Form level menus
  • Additional
  • GoTo
  • File
  • Help

Rule 2: Action Group

All Push Buttons and Button Drop Lists (BDL) in control area (except for a few that belong to an exception list) must be part of Actions Window Ribbon Group.

Some Push Buttons (e.g. field “Ok Button”) if exist in footer of the window should go in to Actions Window Ribbon Group.

Rule 3: Form level menus

Form-level menus are used to add menu items that are specific to a single form. They are created using the form definition window.

Each form level menu will have respective Window Ribbon group when rendered on web client window.

Rule 4: Additional menu

There is a built-in command list (cmdListFormTriggers) that gets rendered as a “Additional” menu on Dexterity window when a form is registered with a trigger (e.g. Trigger_RegisterForm()).

The Additional menu, if it exists on a Dexterity window, must be displayed as the Additional Window Ribbon group on web client window.

Rule 5: GoTo Group

If a “GoTo” button drop list exists in the control area, make it a GoTo Window Ribbon group on the web client window.

Rule 6: Built-in Commands

Several built-in commands are already defined in Dexterity, and can be used in your application. These commands provide access to system-level features, such as the print, print setup, help, copy/paste etc.

The Print (cmdPrint) and Print Setup (cmdPrintSetup) commands from File built-in command will be part of File Window Ribbon group on web client window.

The Help Window Ribbon group on web client window will display the Help menu commands (cmdHelpContents, cmdHelpOnHelp etc).

Additionally, the Window Note will be part of the Help Ribbon group if that button exists in the footer of the window.

To be continued next week.... in this post.

Rushi Patel

For other posts in this series go to: https://blogs.msdn.com/b/developingfordynamicsgp/archive/tags/developer+insights/