Microsoft Press has a new book out: “First Look 2007 Microsoft® Office System“. The book seems to give a good overview of what is new in Office 2007:

“What’s inside the newest release of the Microsoft Office system? How will the new interface change the way you work and make you more self-sufficient and effective? How can your business put the new workflow capabilities to work right away in this new world of work? With FIRST LOOK 2007 MICROSOFT OFFICE SYSTEM, well-known author and columnist Katherine Murray gives you an special introduction to the next generation of Microsoft Office. You’ll get an expert overview of new and enhanced applications, features, and capabilities in addition to advance insights and straight talk from the Office product group, Discover the new user interface and revolutionize the way you use Office; learn about the Live Preview feature that allows you to see how a format will look before you make a change; introduce yourself to the new collaboration products and services, including Microsoft Office Groove. In addition, learn about enhancements to existing Office applications, including new graphics capabilities in Microsoft Office PowerPoint, easier database creation with Microsoft Office Access, easier time-management capabilities in Microsoft Office Outlook, and improved charting capabilities in Microsoft Office Excel. It’s an exclusive, guided preview for business decision makers, early adopters, and users—and anyone else who wants to start planning and hit the ground running with the next generation of Office.”

Best of all, you can download it as pdf for free from the 2007 Microsoft Office Learning Portal.

Thanks to Bob Buckland for pointing out this out!

Callbacks are a fundamental feature of RibbonX. It is therefore important for developers to understand when they are executed and when they may fail. As a principal rule, callbacks shouldn’t assume anything and should protect themselves against all potential failures. Let me illustrate some of the difficulties with the following example.

Revisiting the StyleChooser add-in

V1.2.1 of my StyleChooser add-in contained a callback that failed. To reproduce the error, you can download V1.2.1 and its source code. Install it and open Word. Before you continue, make sure that UI errors of add-ins are being displayed (Word Options, Advanced, General section, Show add-in user interface errors). With the Home tab displayed, switch to the Full Screen Reading mode via the status bar. In that mode, click on Print Layout. You should then see a CustomUI error message: An exception occured while calling function “GetText”. The exception message is: This method or property is not available because typing is not currently allowed for reading.

What happened? GetText looks like this:

Public Function GetText(ByVal control As IRibbonControl) As String

If control.Id = “comboStyleChooser” Then

Dim selection As Microsoft.Office.Interop.Word.Selection = DirectCast(applicationObject.Selection, Microsoft.Office.Interop.Word.Selection)

Return formattedStyle(DirectCast(selection.Style, Microsoft.Office.Interop.Word.Style))

End If

Return “”

End Function

The error is caused by the call selection.Style as Word is still in the Full Screen Reading mode when the callback is being executed. In that mode, this particular call is not allowed. I fixed this problem with V1.2.2 by wrapping the call in a try-catch statement (download source code). I assumed this to be a bug in Word 2007 and submitted it to Microsoft as such. Unfortunately, Microsoft couldn’t fix the issue as executing callbacks when the ribbon was already displayed caused some serious flickering.

Don’t assume anything

Therefore add-in developers need to ensure that callbacks don’t make any assumptions. A callback cannot assume that a particular document is open or that the application is in a particular mode:

Callbacks might be executed before the user interface or any particular document is displayed or available via the object model.

Callbacks should not assume anything and should be ready to be called at any time. They therefore need to check for various conditions to prevent errors like the one in my StyleChooser 1.2.1 version. This applies to all RibbonX callbacks, not just to those implemented by COM add-ins.

20 days ago, Microsoft announced the ODF translator project. Brian Jones clarified a few issues in another blog post a few days later. Currently, an early version of the ODF translator project is available for Word. It integrates into Word as an add-in. You can download a copy as well as the full source code from sourceforge.

One of the most contentious issues became right away how the ODF add-in integrates into Word. Brian claimed:

“It’s directly exposed in the UI. We’re even going to make it really easy to initially discover the download. We already need to do this for XPS and PDF, so we’ll also do it for ODF. There will be a menu item directly on the file menu that takes to you a site where you can download different interoperability formats (like PDF, XPS, and now ODF).

Heck, if you wanted to be even more hardcore, the Office object model allows you to capture the save event. So if you wanted to you could make it so that anytime you hit save you always used the ODF format, just by capturing the save event and overriding it. I’m not expecting folks to do that, but it does show just how extensible Office really is. ”

The following screenshot shows the default integration as an ODF menu item in the Office button menu with an associated flyout containing the Open and Save commands:

It didn’t take long for the criticism to start. Rob Weir, for example, critiqued in his blog post that ODF cannot be found in the Save As and Open dialogs nor can be made the default file format.

As this is an UI issue, I decided to take a closer look.

The facts

• Let me start out with one simple fact: The ODF translator add-in has to make do with what currently exists in the Office 2007 extensibility model. Why?
  
• Microsoft is providing ODF support as an add-in, not as a built-in feature. That means, the add-in is limited to what every other Office add-in can do. As it is not a built-in feature, Microsoft was able to announce it as an open source project.
• Microsoft isn’t going to provide any special MS-only hooks in Office 2007 just to integrate the ODF, PDF & XPS things into it. MS-only hooks would just be a waste of development resources and non-MS add-in developers would want to use them as well (which would be simple due to the open source nature of the ODF translator project). Hence, this is either going to happen through a normal Office 2007 add-in mechanism, or not at all.
• The Open & Save As dialogs cannot be customized: There simply is no way for an add-in to add another file format to the file type list in those dialogs. I checked this with the Office beta team just to be sure.
• It is possible to write a custom file import/export converter for Word. This would add the file type supported by the converter to the file type lists in the Open and Save As dialogs. Unfortunately, this is not an option for the ODF translator project. Such a custom converter would convert between RTF and the desired format, which simply misses the point for the ODF translator add-in. For more details, see the respective MS KB article.
• The ODF translator add-in is therefore limited to what can be done via RibbonX.

Why not provide the ability to customize the Open and Save As dialogs?

• ODF support was clearly an after-thought for Office 2007. It was announced after the release of Beta 2. Office 2007 was for the most part feature complete with Beta 2 and it is therefore extremely unlikely that Microsoft is going to make any substantial changes to the extensibility model between now and RTM.
  
• Why should MS waste resources on providing one particular feature for add-in developers that most Office add-in developers (all not affiliated with Microsoft) would put at the very bottom of their wish list? How many add-ins would actually use such a feature (answer: 3; ODF, PDF, XPS). Sorry, but providing such a feature to satisfy 3 add-ins is a real waste. There is so much missing in Office 2007 from the point of view of an add-in developer, that MS has enough work for the entire next release (after 2007) before even considering the Open & Save As dialogs issue.
• For more about this, see my blog comment.

The RibbonX side of it

If you download the source code, you’ll find a file named “customUI.xml” in the OdfConverter\source\OdfWord2007AddIn\resources folder. The file contains the RibbonX code that the add-in uses:

This RibbonX snippet shows how simple the integration of this add-in into the Office button menu is. Let’s see how we can modify this.

The first modification we can easily make is to get rid of the ODF menu and integrate it differently into the menu. The following screenshot shows the Open ODF command directly below the Open command, and integrates the Save as ODF command into the Save As flyout:

In order to accomplish this, we’ll need to use the following RibbonX:

The modification of the splitButton “FileSaveAsMenu” shown above adds an item to the Save As flyout. The “insertAfterMso” attribute specifies the exact position in the flyout menu and in the menu itself. You can see from this example that the order of the items in the XML code doesn’t matter when we use this attribute. The Open ODF button is in the XML below the modification of the Save As flyout, but the button nonetheless right after the built-in Open button.

The only effort required to use this customization is to change the “customUI.xml” file and rebuild the add-in with Visual Studio 2005.

Providing our own Open and Save As dialogs

A much more sophisticated customization is to replace the existing Open and Save As dialogs with our own ones and also to override the Save command. This should never be used for add-ins in an uncontrolled environment, as my UI style guide explains. I would like to discuss the option here though, because of the way I see the ODF add-in being used:

Most average users really don’t care about ODF vs. OpenXML. All they want to do is save their files and they are hardly ever going to change the default file format anyhow. As Brian has pointed out before, ODF doesn’t support all of what OpenXML supports, and hence ODF is not useful for most users as the default file format for Office 2007 (lack of full fidelity).

Most people who will use ODF will do so due to company/agency policy. That means, the ODF add-in will be preinstalled for them by their network administrators. Network administrators can easily change the add-in (one of the benefits of open source) in such a manner that ODF will be the default for open and save. Everyone else who downloads the ODF add-in, will actually know what they are downloading and will have no problem finding it at its prominent location in the Office button menu.

That means, I see this add-in either use in a controlled environment where repurposing is no problem, or by power users who can either choose to use the repurposed version or easily use the menu items in the Office button menu.

In order to override the built-in features and render ODF the de facto standard file format, we’ll need to override three things: Open, Save and Save As. In RibbonX, the result looks like this:

You might be wondering about the enabled=”false” in this and all previous RibbonX snippets. The code for saving in the ODF format isn’t implemented yet in the Word add-in that was released on July 5, 2006. Once it is implemented, those attributes can simply be removed. The above RibbonX code assumes that ExportODF handles the different behavior of “Save” and “SaveAs”.

In the C# code of the add-in itself, the signatures for ImportODF and ExportODF need to be changed to:

public void ImportODF(IRibbonControl control, ref bool fCancelDefault)

public void ExportODF(IRibbonControl control, ref bool fCancelDefault)

fCancelDefault determines whether the built-in action is executed after the repurposed action or not. If fCancelDefault is true, then the built-in action will not be executed. For the ODF add-in, fCancelDefault should be returned as true therefore.

This modification changes the default file format of Word 2007 to ODF. At the same time, it doesn’t allow the user to save in any of the built-in file formats. In order to make this add-in behave more realistically, the Open and Save As dialogs in the add-in should include the default file formats and trigger the respective action via the Word object model. In addition, when ODF was chosen as file format, the add-in should disable all functionality in Word that cannot be saved in ODF. This is similar to the Compatibility Mode in Word 2007: When working on a Word 97-2003 file, features that are specific to Word 2007 are not available. I could imagine e.g. that SmartArts would be disabled in an ODF Compatibility Mode. Maybe someone in the community is going to implement such a more advanced add-in and it will be provided as an alternative on sourceforge?

Virtual PC 2004 SP1 from Microsoft is now available for free. Virtual PC 2007 will be available for free as well. There is no better way to beta test Office 2007 than to run it in a virtual machine. Download VPC from Microsoft now.

A firewall is generally a good idea. However, waking up and suddenly having lost access to my email and files (both hosted on my own server on the campus of my university) is definitely not fun. After I couldn’t connect to my server at all, I went there and it was running just fine. I even could connect from the server to my desktop at home using RDP.

A phone call to my helpdesk solved the mystery: The IT department of my university had installed a firewall on Monday for my entire department preventing access to on-campus machines (except the official department servers). [Note that the university has long since had a firewall in place, but an extremely open one.] Apparently though they hadn’t severed all existing connections until last night, which is why I only discovered this today. The workaround is to use the VPN offered by Lehigh University. Unfortunately, they didn’t bother providing an easy way to configure it (e.g. using the Connection Manager Administration Kit) besides a few screenshots. Whoever follows their instructions will therefore be stuck with a VPN that doesn’t use split tunnel, and hence cause some serious performance issues. For anyone associated with Lehigh reading this, I provide the needed Connection Manager configurations (with and without split-tunnel) on my new Lehigh VPN page.

To all the network administrators reading this: If you install a firewall that has such a drastic impact, especially if you do this on a university campus, please tell ALL your users beforehand. My university’s IT department might have told faculty members about this, but they should have clearly informed all staff, faculty and students, especially when the Computer Science department is affected! I would have been much happier to find out about this change in an email last week.