In previous versions of Office, you created menus and toolbars by using VBA to manipulate the objects that make up the CommandBars object model (see Chapter 15). The code to do that for a non-trivial application often extended to hundreds and sometimes thousands of lines of VBA that proved hard to maintain when menus were added, removed, or rearranged. For some time, best practice has been to use a table-driven approach to building menus, in which the menus and toolbars were defined by filling in a table on a worksheet and a dedicated (and reusable) VBA procedure interpreted the table to create the menus and toolbars. Even when using a table-driven approach, you still needed quite a bit of custom VBA to ensure that specific menus were visible only when their workbook was active, and had to be extremely careful about removing customiza-tions when the workbook was closed.

When designing the programmability model for the Ribbon, Microsoft started with the current best practices, identified the remaining pain points, and removed them. It took the resultant architecture on a world tour of key clients and other interested parties, listened to all their issues, and modified the RibbonX design to resolve most of the issues that were encountered. The result is an entirely new paradigm for the Excel developer, in which:

□ The customizations are defined at design-time, rather than coded individually. Instead of using a table in a worksheet (which would only be available in Excel), they're defined using XML and stored as a custom part in the XML file formats (for all the Office applications that have the Ribbon).

□ When the workbook is opened, Excel automatically reads the XML part and applies the cus-tomizations to the Ribbon.

□ If a standard workbook is used, its Ribbon customizations are only applied and visible when that workbook is active.

□ If an add-in workbook is used, its Ribbon customizations are always applied and available.

□ Whenever a workbook is closed, its Ribbon customizations are automatically removed.

□ Even though the customizations are defined at design-time, most of the controls' attributes can be modified at run time, using VBA (such as enabled, visible, label, and so on).

□ A few of the controls can be totally dynamic — so their structure as well as their attributes can be defined at run time, using VBA.

□ All the built-in controls are available for our use and can be overridden, executed, and queried for their images, caption, and so forth.

0 0

Post a comment