Office hat ein neues Dateiformat und das basiert auf XML. Genauer gesagt Open XML. Das klingt so nach OpenSource. Ist es auch. Wo Open drauf steht, ist auch Open drin. Das Format ist komplett offen gelegt und bei der ECMA eingereicht zur Standardisierung.

Für Entwickler bedeutet das:

• Logische Trennung von Format und Daten
• Zip Container
• Zugriff auf die Bestandteile per WinFx API (System.IO.Packaging)
• Kein Zugriff über Office Objektmodell nötig
  und damit
• endlich sichere Server Szenarien
• Daten hinzufügen, austauschen oder Datei komplett neu erzeugen

Es gibt auch schon ein Forum der ebenfalls neuen Open XML Developer Group: die OpenXMLDeveloper.org.
Ziel ist es, für Entwickler ein Forum zum Austausch von Ideen, Tips und Tools rund um das Thema Open XML File Format von Office 2007 zu schaffen. Neben Apple, Intel, Microsoft und dem Florida House of Representatives ist u.a. auch die Stuttgarter Softwarefirma (Microsoft Gold Certified Partner) ITVT GmbH der Brüder Jochen und Steffen Klipfel unter den Gründungsmitgliedern.

Office 12 - oder 2007 Microsoft Office System - wirft seine Schatten voraus. Zum ersten Mal wird der breiten (Developer-) Öffentlichkeit die neue Version des Office Paketes vorgestellt. Wo? In Redmond, auf dem Microsoft Campus. Ich spreche - bzw. schreibe - von der ODC, der Office System Developer Conference.

Integration der eigenen Anwendung in Office ist inzwischen hoffähig geworden. Macht ja auch Sinn, die Daten und Informationen dorthin zu bringen, wo die Anwender arbeiten. Nur waren die Tools bisher noch ganz schön limitiert.

In Office 2007 gibt es keine Menüs mehr! Punkt. Cool. Endlich weniger Konfusionen. Platz gemacht haben die über 1000 Befehle einer neuen Struktur namens Ribbons (ich bin gespannt auf die deutsche Übersetzung...). Ribbons bringen eine kontextsensitive Präsentation der verfügbaren Befehle. Eine Art tabbed Dialog. Somit ist nur noch das zu sehen, was auch gerade Sinn macht im aktuellen Kontext.

Können wir das als Programmierer nutzen für eigene Erweiterungen? Klar. Das Stichwort ist RibbonExtensibility. Selbiges basiert auf XML. Was sonst. Die Ribbons werden also in XML deklariert. Die Office Programme wiederum interpretieren das XML und extrahieren daraus die Information, die nötig sind, Ribbon Chunks (funktionelle Gruppen) und darin Galleries (visuelle Repräsentationen des zu erwarteneden Ergebnisses) und Befehle zu erzeugen.

So könnte ein Ribbon XML File aussehen:

<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
 <ribbon>
  <tabs>
   <tab id="MyCompany" label="Jens' Enterprise">
    <group id="HRGroup" label="Employees">
     <gallery id="galleryEmployees" label="Employees"
              size="large" columns="1" getImage="getImage"
              showLabel="false" onAction="GetEmployeeDetail"
              getItemImage="getItemImage" getItemCount="getItemCount"
              getItemLabel="getItemLabel">
     </gallery>
    </group>
   </tab>
   <tab id="tabInsert">
     <group id="InsertEmployeeData" label="Insert Data">
       <button id="InsertButton" label="Insert Employee Data"
               size="large" onaction="EmployeeActionHandler">

     </group>
   </tab>
  </tabs>
 </ribbon>
</customUI>

Integration in diese Art von Interface bedeutet für den Entwickler, welcher den UI Guidelines folgen möchte, seine geplante Funktionalität aufzuteilen. Funktionelle Gruppen zu definieren. Alles, was eingefügt werden kann, gehört in den Tab "Insert" usw. Die Anwender werde es danken. Und wenn wir nur ein eigenes Interface anzeigen und all den "Rest" von Excel oder Word weglassen wollen? Auch kein Problem. In der Deklaration des/der eigenen Ribbon(s) einfach StartFromScratch auf True setzen. Das führt dazu, daß beim Laden des eigenen UIs das komplette Standard UI verschwindet. Machen Sie das mal bei der Menüstruktur von Office 2003...

Hin und wieder werde ich gefragt, wie man denn in einer Installer-Klasse den Pfad ermitteln kann, in dem die Anwendung gerade installiert wird.

Dazu vielleicht ein wenig ausgeholt: Der Windows Installer kennt sogenannte Custom Actions. Dabei handelt es sich um selbst geschriebenen Code, welcher während der Installation ausgeführt wird. Unter .NET können wir diese Custom Actions mit managed Code schreiben, als sog. Installer Class.

Prinzipiell gibt es 4 Custom Actions, die wir verwenden können: Install, Commit, Rollback und Uninstall. Install und Commit werden während der Installation zu verschiedenen Zeiten ausgeführt. Rollback, wenn etwas schief läuft und alles auf den Ausgangszustand zurückgesetzt werden muß. Hier sollte auch alles wieder entfernt werden, was in den vorangegangenen Custom Actions erzeugt wurde. Und Uninstall ist wohl selbsterklärend. 

Um bspw. Den Installationspfad zu ermitteln, können wir Properties des Windows Installers verwenden, in diesem Falle TARGETDIR. Auf diese Variable schreibt der MSI den bei der Installation ausgewählten Pfad. Über die Property CustomActionData der ausgewählten Custom Action wird ein Parameter deklariert, auf welchen dann der Inhalt von TARGETDIR geschrieben wird: /InstallPath="[TARGETDIR]"

Zugegriffen werden kann auf diesen über die Parameters Collection des Context-Objekts: 

  Public Overrides Sub Commit(ByVal savedState As System.Collections.IDictionary)

    Dim sInstallPath As String = Me.Context.Parameters("InstallPath")

    ...

    MyBase.Commit(savedState)

  End Sub

Am Ende nicht vergessen, die entsprechende Methode des Basisobjekts aufzurufen, es sei denn Sie übernehmen die komplette Steuerung der Custom Action.

Prinzipiell können alle public Properties (die in Großbuchstaben) verwendet werden.