Full Specifications. What's new in version 4. Release March 11, Date Added March 11, Version 4. Operating Systems. Additional Requirements Microsoft Office Total Downloads 5, Downloads Last Week 0. Report Software. Related Software. Open, edit, and save files using the new file formats in versions of Word, Excel, and PowerPoint. LibreOffice Free. Enhance your document production and data processing with feature-rich apps.
Create, open, and edit Office documents. Office Tab Free to try. The ribbon is a visual tool, not a text-based menu system. Similar tasks are grouped together under tabs. Commands are no longer buried in menus and submenus. Just click a tab to find the one you need!
In moving away from the old UI, Microsoft is also leaving behind a lot of familiar terminology and replacing it with new and unfamiliar concepts. Let's start by going over the basics of the new UI to ensure we're all on the same page.
Ribbon The large rectangular region above the document is known as the ribbon. RibbonX applies mainly to the ribbon and everything inside of it. Office Button This button drops the Office Menu, which is the rough equivalent of the File menu in previous releases of Office.
The Office Menu contains commands that act on documents rather than on the contents of documents. RibbonX add-ins can freely alter the contents of the Office Menu though they cannot customize the Office Button itself. Quick Access Toolbar This toolbar contains commonly used commands and is the main location for end-user customizations.
Users can right-click on any ribbon control and add it to the Quick Access Toolbar including custom RibbonX controls. Because it's meant to be the space that "belongs" to the end user, RibbonX add-ins are not usually allowed to alter the Quick Access Toolbar unless they have enabled StartFromScratch mode.
Tabs The tabs make up the main content of the ribbon and contain UI controls that deal with the contents of the document at hand. RibbonX add-ins can create their own custom tabs and alter the visibility and labels of the built-in tabs. Contextual Tabsets When objects such as pictures or tables are selected inside the document, contextual tabsets appear and contain all the UI elements for dealing with those objects.
RibbonX add-ins can alter the visibility of built-in tabsets and add custom tabs to them. One feature not supported in the Office release is the creation of custom contextual tabsets. Tabsets contain contextual tabs, which otherwise behave the same way as regular tabs.
Groups Tabs contain sets of groups, which in turn contain individual UI controls. RibbonX add-ins can alter the visibility of built-in groups and create their own custom groups. One thing they cannot do is alter the contents of built-in groups. This restriction protects the UI layout and guards add-ins against conflicts with each other and future versions of Office. Groups optionally have dialog box launchers in the corner that display dialogs relevant to the group such as the Font or Paragraph dialogs.
Task Panes Several task panes still exist in the Office system, and it's now possible to have more than one open at a time. MiniToolbar The MiniToolbar is a collection of common formatting commands that appears above text selections and right-click context menus. RibbonX add-ins cannot modify the contents of the MiniToolbar, but they can disable or repurpose the built-in commands on it. Context Menus These are the same right-click context menus that we all know and love from previous versions of Office.
In the Office release, RibbonX does not apply to context menus, but they can be extended and customized using the CommandBars object model just as they could in the past.
Status Bar The status bar contains several handy new controls, such as word count and the view slider. The status bar cannot be customized by add-ins in the Office system, though it can be hidden. If you already have add-ins written against Office , you might wonder whether they will still work in the release. Happily, the answer is yes, they will still work just fine unless they do crazy things like checking the version of Office and refusing to run on newer releases.
All of the old menus and toolbars still exist under the covers for the simple reason that legacy add-ins that manipulate them still need to run on the Office system. How do they show up in the new UI?
Let's take a look at an example. Figure 2 shows a hypothetical Word add-in that creates a custom toolbar and adds a few buttons to the old menus and toolbars, along with how it looks when loaded in Word As you can see, when a legacy CommandBar add-in is loaded, the Add-Ins tab shows up in the ribbon. The Menu Commands and Toolbar Commands groups contain custom controls that were added to the legacy built-in menus and toolbars, respectively.
They will also display any legacy built-in controls that were repurposed by add-ins to perform custom actions by setting the OnAction or Hyperlink properties. The Custom Toolbars group displays any legacy custom toolbars as horizontal sections. The tooltips of the controls show the name of the legacy toolbar they are from. In the event a misbehaved add-in leaves behind buttons after it is uninstalled, the user can right-click on the controls in the Add-Ins tab and delete them from the legacy CommandBar structure.
Instead of writing complicated code that builds up the UI using a series of object model calls, you can create an XML file that specifies the appearance of the UI in a structured markup form.
This has numerous advantages for the add-in writer. First, you're separating the UI from the code. The UI designer doesn't need to know how to update the code manually in order to try out new designs. In fact, if the add-in chooses to load its XML from an external file, the UI can be modified and perfected without even recompiling the add-in. This eliminates the middle step from the iterated Edit, Compile, Run cycle required by hardcoded UI systems. Second, the add-in's complete UI is known by Office.
This may not sound significant until you realize that with CommandBars, previous versions of Office had no idea which toolbars and menus belonged to which add-in. All of the UI modifications came in over COM calls, which were not traceable back to any individual add-ins.
This led to several annoying problems, which can now be avoided completely. Third, Office can automatically clean up an add-in's UI. Previously add-ins had to have special code that went through and deleted their menus and toolbars on shutdown or uninstall.
If the add-in crashed or failed to clean itself up properly as many did , it would leave useless buttons in the UI. Since the Office system cleans up add-in UI automatically, there's no need to write any cleanup code and no possibility that there will be left-over UI. Versioning between different releases of Office is another issue you'll avoid.
Valid XML files are required to contain an xmlns namespace declaration that identifies which schema version they comply with. This provides RibbonX with information about which version of Office a particular add-in targets and allows it to map the UI appropriately, given any changes that might have occurred between versions.
The lack of versioning and ownership in the CommandBars object model are two of the main reasons that legacy add-ins often broke when upgrading to new releases of Office and that the Add-Ins tab is unable to better distinguish between the jumble of controls added to it by the OM calls. Finally, XML has good tool support. The CommandBars object model can be described as using a "push" model, where add-ins are pushing all of the UI data to Office by setting various properties in the object model.
Each property of the controls in the UI must be explicitly set by the add-in at startup, even if the menu or toolbar where that control lives is never shown. If this involved loading up a large number of image files, it could be quite expensive, performance-wise. RibbonX uses a "pull" model, where Office pulls the data from the add-in only when it's needed. Instead of setting properties like CommandBar. Name or CommandBarButton. Picture, add-ins provide get callbacks, such as getLabel or getImage.
Office calls these callbacks when it needs to know what the label or image of a control is. Quickly search and add any controls. Where is the Customize feature?
How to add a build-in button? How to set Key Tip for controls? How to set Keyboard Shortcut for controls?
0コメント