If you've started up a computer with an Office application during the past couple of years, you probably met up with the Ribbon. This ingenious visual element of the Office package revolutionized the way we perceive working with documents. In this article, we'll take a closer look at it, and even learn how to use the Ribbon Framework to suit our own programs.
Contributed by Gabor Bernat Rating: / 2 October 15, 2009
At first, Microsoft was cautious about disclosing how they handled the Ribbon. This is understandable; they invested significant money in research to come up with the idea, and then in a developer team to execute it. Eventually, along with the visual and functionality upgrade for the Microsoft Foundation Class Library, they launched the first module showing how you could use their "invention" in your own application.
In the early days, Microsoft tried to patent the ribbon. This failed, because the concept itself (tabbed toolbars) could be observed in some earlier applications on the Internet. Nevertheless, you had to sign the Office Fluent License Agreement if you wanted to use it. Only after doing this could you have access to the Design Guidelines (meanwhile, they are published on the MSDN, available to anyone).
Then again, the MFC approach was a little bothersome; although it works flawlessly you need to code the addition of each item yourself. Arranging items to be as user-friendly as possible resulted in countless synchronization hours between the design team and the coding team of the application. With the build of the Ribbon Framework, this problem should vanish.
The solution was to involve the designers in the creation of the application. As designers are not famous for their coding background, the team split up the job at hand into two tasks. The designers now take care of how everything looks with XAML markup code. The coding team implements the functionalities of the controls inside the ribbon.
While this is not as good as throwing out a list of controls, the mainframe of the ribbon has an editor where you can add/delete and move around controls; it is a step ahead. Now every designer that takes the effort to become familiar with the existing controls inside the framework (read learn names and configuration parameters) and is not too lazy to write a couple of lines into an XMAL file can modify the application on his or her own.
For example, suppose that we have a checkbox in our application that defines some trait. From point of view of the programmer, the behavior should be the same even if we change the text box to a combo box with true and false values inside. The coder only needs to know what input and output parameters a command uses. What control the command uses to get those parameters is up to the designer. This is called the intent-based model.
Throughout this article, I will try to present to you the structure of the markup language used for the framework as simply as possible. Before I do this, I feel that you should also have a basic idea of how it works. The image below should make the rest of this article a little easier to understand:
The controls are the items you can see inside the ribbon. Both a simple checkbox and a complex font-selecting tool are controls. You can bind a command to both of them. For the first, the application reacts to the change of the checkbox (a simple bool variable), while with the second, the same thing happens on a larger scale, and more information is sent (a font settings variable).
Therefore, from the point of view of the functionality of a control, the programmer only needs to know when the state changes in the case of a control, and what the change is. It needs to respond in the same way if the font changer tool is a simple font size increaser or a completely new font and attributes setter.
It is up to the designer to set how the application looks. We can make any change to a control as long as we specify what command name will handle its state change. The tool of the designer is the Extensible Application Markup Language (XAML). The XAML is an extension of the XML language. Once we complete this file, we can compile it into binary code that the framework can link with the commands written by the programmer.
From my previous paragraph comes the idea that an XAML file will have two parts. In one we will specify the commands and what resources to use for them (a command and resource tree). In the other we will describe how the ribbon should look and what items it will contain (a views tree).
On the following page I will present the code itself; therefore, if you want to follow along with me step-by-step, you need the Windows 7 operating system, the Windows 7 SDK and Visual Studio (I will use 2008 with SP1).
I must confess that in this article I will not be able to present the creation of the ribbon all the way to the end. The C++ part will be the subject of a future article. However, this should be enough to give you a grasp of the XAML section. My next article will build on this and use what we created. Nevertheless, in order for you to get a visual idea of what we are doing, I will present some pictures from the final product.
Writing an XML file from scratch without any help from the Intellisense can become a bit fiddly. To get Intellisense working with your XML you need to add the schema file (at %Install_directory%WindowsBinUICC.xsd) to %Install_directory%Microsoft Visual Studio 9.0XmlSchemas. After this, start your XML code with the following schema definition:
The compiler that checks if your XML is correct uses this same schema. This way you can see your mistakes as you write, and you can see what options you have:
The ribbon lets you choose from many traits. Most of them have default values set; the framework will apply these defaults if you do not specify otherwise. Nevertheless, let's return to the command part.
First, we mark that we will define commands. Then we create five commands. The examples above illustrate how, for some values, we can let their default values define some attributes (or not). In case of the first command, we just declared the name and the text you will read on it.
For the second command, we also defined an ID and a symbol for it. For the last command, we set a tooltip and custom images for it. The large image will be used if possible, while the small will be used only after the ribbon has been resized to a point where a smaller image is required.
Of course, there exist many more controls available inside the new ribbon:
In the framework, every command can have an image assigned to it (and all the other traits). At first, it seems as if it would not make sense to define an image for a group, for instance. However, I need to remind you that if you start up an office, you can add even a group to the quick access toolbar. In this case, the Quick Access toolbar needs to show an image, does it not? As for the layout part, the configuration code should look as follows:
<Application.Views>
<Ribbon>
<Ribbon.Tabs>
<Tab CommandName="HomeTab">
<Group CommandName="MainGroup"
SizeDefinition="OneButton"
ApplicationModes="0,1">
<ToggleButton CommandName="ViewSource"/>
</Group>
<Group CommandName="Toogle" ApplicationModes="1">
<Button CommandName="SelectAll"/>
</Group>
</Tab>
</Ribbon.Tabs>
</Ribbon>
</Application.Views>
Then again, you will need the proper images so you can add them to the res directory. The only ones supported are the 32-bit bitmap images. For the commands I used, here are the images:
ViewSourceS.bmp ->
PrintPreviewL.bmp ->
For some straightforward functionality reasons I have decided to make the demonstration on the HTML Edit sample project. This is shipped with any Visual Studio 2008 package. If you want to follow along, just add an XML file to the project and extend it with the above code snippets. Here's a sneak preview of what we will have in the end:
You can add multiple items inside a group. You can define how this will behave with the SizeDefinition. For ease of usage you can look up one of the ones already defined by the developer team here. If you define nothing for one of the groups, the framework will try to deduce from its content what it should use. If the ~20 predefined ones are not good enough, you may define new ones. You can check with the MSDN for how to achieve this.
Probably you have noticed the ApplicationModes tag. What is it? With the help of these you can set up various modes for a program. For instance, you may want to hide a collection of functions from the eyes of a beginner and show it to advanced users. You can turn groups and full tabs on and off with the help of the modes.
Once you have defined during which mode/s a group/tab should appear, you can switch between the modes with a single line of C code. I will show you how to do this in a future article, one that I will be dedicating to the C++ coding section. Nevertheless, let me show you the result now. As soon as you push the View Source button down: voilą.
The tool that will compile and create the necessary binary and resource files that you need to add to the application project is the UUIC.exe. You can find it inside the Windows SDK folders bin subfolder. We could take the console approach to ask the syntax to create this.
However, as long as we are already using Visual Studio, why not let it do the job? We can add a custom pre-build step to the XML file. My XML file has the name: Markup_Ribbon.xml. Select the file inside the solution explorer, right click and go to properties, Custom build step, General. In the command line add the text:
Click OK and build the application. The UICC will complain that we have no Application Menu or Quick Access toolbar defined. However, we do not care about this right now. The default (noting - empty) will do just fine.
This will be all for today. For those of you that cannot wait until next time I am posting the final source code. Feel free to play around with it or experiment with the XML markup language.
I would like to express my gratitude to you for reading through my article and encourage you to jog down your thoughts related to the subject or build up of the article here on the blog. It would mean a lot if you could also rate the article. If you have non-related questions you can join our friendly forum at DevHardware or DevArticles and post them there. Live With Passion!
The Windows Ribbon Framework
