RibbonX-API
Erweitern Sie Office 2007 mit eigenen Multifunktionsleisten-Registerkarten und -Steuerelementen
Eric Faller
Themen in diesem Artikel:
- Eine Einführung zu Multifunktionsleisten
- RibbonX-Steuerelemente und -Funktionen
- Aktualisieren von Add-Ins zur Verwendung von RibbonX
- Erstellen von Add-Ins für Word und Excel
|
In diesem Artikel werden folgende Technologien verwendet:
Microsoft Office 2007
|
Laden Sie den Code für diesen Artikel herunter:
RibbonX2007_02.exe
(201 KB)
Code online durchsuchen
Inhalt
Wenn Sie Microsoft Office 2007 schon gesehen haben, werden Sie bemerkt haben, dass sich die neue Microsoft® Office-Benutzeroberfläche von früheren Office-Versionen radikal unterscheidet. Es dürfte Sie daher nicht überraschen, dass das Erweiterungsmodell für die Benutzeroberfläche ebenfalls völlig neu ist.
Das seit Office 97 zur Verfügung stehende CommandBars-Objektmodell war ähnlich wie die alten Symbolleisten und Menüs, die durch das Modell erweitert wurden, schwierig in der effektiven Anwendung. Das neue Modell heißt RibbonX und weist viele Attribute der neuen Benutzeroberfläche selbst auf: Benutzerfreundlichkeit, Konsistenz, ein modernes Erscheinungsbild und Vorhersagbarkeit für Endbenutzer.
RibbonX trennt die Entwicklung der Benutzeroberfläche von dem zugrunde liegenden Code, indem XML zum Festlegen von Inhalt und Struktur verwendet wird, wobei ein dynamischer Rückrufmechanismus vorhanden ist. Ich werde in diesem Artikel später auf die Einzelheiten eingehen und zuerst auf ein paar Dinge zu sprechen kommen, die erfahrene Office-Entwickler bezüglich der neuen Benutzeroberfläche wissen möchten.
Durch die Aufgabe der alten Benutzeroberfläche lässt Microsoft auch viel vertraute Terminologie zurück, die durch neue, unbekannte Konzepte ersetzt wird. Beginnen wir mit den Grundlagen der neuen Benutzeroberfläche, um sicherzugehen, dass alle dieselbe Ausgangsposition haben. Abbildung 1 zeigt die Bezeichnungen der wichtigen Benutzeroberflächen-Komponenten von Microsoft Office Word 2007.
.gif)
Abbildung 1 Elemente der neuen Word 2007-Benutzeroberfläche (Klicken Sie zum Vergrößern auf das Bild)
1. Multifunktionsleiste Der große rechteckige Bereich über dem Dokument wird als Multifunktionsleiste bezeichnet. Sie enthält die Titelleiste, die Office-Schaltfläche, die Schnellzugriffs-Symbolleiste und die Registerkarten. RibbonX bezieht sich hauptsächlich auf die Multifunktionsleiste und alles, was sich darin befindet.
2. Office-Schaltfläche Diese Schaltfläche ruft das Office-Menü auf, das etwa dem Dateimenü in früheren Office-Versionen entspricht. Das Office-Menü enthält Befehle, die sich auf Dokumente auswirken und nicht so sehr auf den Inhalt von Dokumenten. RibbonX-Add-Ins können den Inhalt des Office-Menüs frei verändern (obwohl sie die Office-Schaltfläche selbst nicht anpassen können).
3. Schnellzugriffs-Symbolleiste Diese Symbolleiste enthält häufig verwendete Befehle und ist der Hauptbereich, in dem Endbenutzer Anpassungen vornehmen können. Benutzer können mit der rechten Maustaste auf ein beliebiges Steuerelement der Multifunktionsleiste klicken und es der Schnellzugriffs-Symbolleiste hinzufügen (einschließlich benutzerdefinierter RibbonX-Steuerelemente). Da dies der Bereich ist, der dem Endbenutzer „gehört“, dürfen RibbonX-Add-Ins normalerweise nicht die Schnellzugriffs-Symbolleiste verändern, es sei denn, dass der StartFromScratch-Modus aktiviert wurde.
4. Registerkarten Die Registerkarten bilden den Hauptinhalt der Multifunktionsleiste und enthalten Benutzeroberflächen-Steuerelemente, die sich auf den Inhalt des jeweiligen Dokuments auswirken. RibbonX-Add-Ins können eigene benutzerdefinierte Registerkarten erstellen und die Ansicht und Beschriftungen der integrierten Registerkarten ändern.
5. Kontextbezogene Registerkartensätze Bei Auswahl von Objekten wie z. B. Bildern oder Tabellen innerhalb des Dokuments werden kontextbezogene Registerkartensätze angezeigt, die alle Benutzeroberflächen-Elemente zur Handhabung dieser Objekte enthalten. Durch RibbonX-Add-Ins können die Ansicht von integrierten Registerkarten geändert und benutzerdefinierte Registerkarten hinzugefügt werden. Eine Funktion, die in Office 2007-Anwendungen nicht unterstützt wird, ist die Erstellung von benutzerdefinierten, kontextbezogenen Registerkartensätzen. Registerkartensätze enthalten kontextbezogene Registerkarten, die sich ansonsten genau wie normale Registerkarten verhalten.
6. Gruppen Registerkarten enthalten Sätze von Gruppen, die wiederum einzelne Benutzeroberflächen-Steuerelemente enthalten. RibbonX-Add-Ins können die Ansicht von integrierten Gruppen verändern und eigene benutzerdefinierte Gruppen erstellen. Allerdings können sie nicht den Inhalt integrierter Gruppen ändern. Diese Einschränkung schützt das Benutzeroberflächen-Layout und Add-Ins vor Konflikten miteinander und mit zukünftigen Versionen von Office. Optional haben Gruppen in der Ecke Dialogfelder-Startprogramme, die für die Gruppe relevante Dialoge anzeigen (z. B. die Schriftart- oder Absatzdialoge).
7. Aufgabenbereiche Es gibt auch bei Office 2007 noch mehrere Aufgabenbereiche, und jetzt ist es möglich, mehrere auf einmal zu öffnen. COM-Add-Ins können nun CustomTaskPanes erstellen, die Inhalt wie beispielsweise ActiveX®-Steuerelemente oder Windows® Forms-Steuerelemente hosten. (Die CustomTaskPane-Funktion unterscheidet sich von RibbonX und wird in diesem Artikel nicht behandelt).
8. MiniToolbar Die MiniToolbar ist eine Ansammlung von häufig verwendeten Formatierungsbefehlen, die über ausgewählten Texten und über Kontextmenüs für die rechte Maustaste angezeigt wird. RibbonX-Add-Ins können den Inhalt der MiniToolbar nicht ändern, aber sie können die integrierten Befehle deaktivieren oder für andere Zwecke verwenden.
9. Kontextmenüs Dies sind dieselben, mit rechtem Mausklick aufrufbaren Kontextmenüs, die wir alle aus früheren Office-Versionen kennen und zu schätzen wissen. In Office 2007 wird RibbonX nicht für Kontextmenüs angewendet, doch sie können wie in der Vergangenheit mit dem CommandBars-Objektmodell erweitert und angepasst werden.
10. Statusleiste Die Statusleiste enthält mehrere nützliche, neue Steuerelemente, wie z. B. „Wörter zählen“ und „Schieberegler anzeigen“. Die Statusleiste kann in Office 2007 nicht mit Add-Ins angepasst werden, aber sie kann ausgeblendet werden.
Unterstützung für vorhandene Add-Ins
Wenn Sie bereits Add-Ins für Office 2003 geschrieben haben, fragen Sie sich möglicherweise, ob diese bei den Office 2007-Anwendungen noch funktionieren werden. Die Antwort lautet ja – sie funktionieren noch immer, es sei denn, es handelt sich um ungewöhnliche Funktionen, bei denen beispielweise die Office-Version geprüft und ein Starten in neueren Versionen verweigert wird. Alle alten Menüs und Symbolleisten sind noch im Hintergrund vorhanden, und zwar aus dem einfachen Grund, dass ältere Add-Ins zu ihrer Bearbeitung noch in Office 2007 ausgeführt werden müssen. Wie werden sie in der neuen Benutzeroberfläche angezeigt? Sehen wir uns ein Beispiel an.
Abbildung 2 zeigt ein hypothetisches Word 2003-Add-In, das eine benutzerdefinierte Symbolleiste erstellt und den alten Menüs und Symbolleisten ein paar Schaltflächen hinzufügt, und sein Erscheinungsbild, wenn es in Word 2007 geladen wird.
.gif)
Abbildung 2a Dieselben Add-Ins in Word 2003 und Word 2007
.gif)
Abbildung 2b
Wie Sie sehen können, wird die Add-In-Registerkarte auf der Multifunktionsleiste angezeigt, wenn ein älteres CommandBar-Add-In geladen wird. Die Add-In-Registerkarte enthält drei Gruppen: Menübefehle, Symbolleistenbefehle und benutzerdefinierte Symbolleisten. Die Menübefehls- und Symbolleistenbefehlsgruppen enthalten benutzerdefinierte Steuerelemente, die den älteren, integrierten Menüs beziehungsweise Symbolleisten hinzugefügt wurden. Hier werden auch ältere integrierte Steuerelemente angezeigt, denen mithilfe von Add-Ins (durch Einstellen der OnAction- oder Hyperlink-Eigenschaften) die Durchführung anderer benutzerdefinierter Aktionen zugewiesen wurde. In der benutzerdefinierten Symbolleistengruppe werden ältere benutzerdefinierte Symbolleisten als horizontale Abschnitte angezeigt. Die QuickInfos der Steuerelemente zeigen den Namen der älteren Symbolleiste an, auf die sie sich beziehen.
Falls ein fehlerhaftes Add-In nach der Deinstallation Schaltflächen hinterlässt, kann der Benutzer mit der rechten Maustaste auf die Steuerelemente auf der Add-In-Registerkarte klicken und sie aus der älteren CommandBar-Struktur löschen.
Neue Funktionen von RibbonX
RibbonX modernisiert die Office-Programmierung mit XML-basierter Benutzeroberflächen-Deklaration. Statt komplizierten Code zu schreiben, der die Benutzeroberfläche mithilfe einer Reihe von Objektmodellaufrufen erstellt, können Sie eine XML-Datei erstellen, die die Darstellung der Benutzeroberfläche in einem strukturierten Markup-Format angibt. Dies hat für den Add-In-Autor zahlreiche Vorteile.
Zum Einen wird die Benutzeroberfläche vom Code getrennt. Der Entwickler der Benutzeroberfläche muss nicht wissen, wie der Code manuell aktualisiert werden muss, um neue Entwürfe auszuprobieren. Tatsächlich kann die Benutzeroberfläche geändert und perfektioniert werden, ohne das Add-In erneut zu kompilieren, wenn das Add-In sein XML-Format aus einer externen Datei lädt. Dadurch entfällt der Zwischenschritt aus dem Zyklus „Bearbeiten – Kompilieren – Ausführen“, der bei hartcodierten Benutzeroberflächen-Systemen erforderlich ist.
Zum zweiten ist Office die vollständige Benutzeroberfläche des Add-Ins bekannt. Dies mag nicht sehr bedeutsam klingen, bis klar wird, dass bei CommandBars für frühere Versionen von Office nicht klar war, welche Symbolleisten und Menüs zu welchem Add-In gehörten. Alle Änderungen der Benutzeroberfläche wurden über COM-Aufrufe verursacht, die sich nicht zu einzelnen Add-Ins zurückverfolgen ließen. Dies führte zu ärgerlichen Problemen, die nun vollständig vermeidbar sind.
Drittens kann Office automatisch die Benutzeroberfläche eines Add-Ins bereinigen. Bislang brauchten Add-Ins besonderen Code, der beim Herunterfahren oder Deinstallieren die Menüs und Symbolleisten des jeweiligen Add-Ins löschte. Wenn das Add-In abstürzte oder keine richtige Bereinigung durchführte (was bei vielen der Fall war), verblieben nutzlose Schaltflächen auf der Benutzeroberfläche. Da Office 2007 die Add-In-Benutzeroberfläche automatisch bereinigt, muss kein Code zur Bereinigung geschrieben werden, und es besteht nicht die Möglichkeit, dass Reste einer Benutzeroberfläche zurückbleiben.
Die Versionskontrolle bei verschiedenen Office-Versionen ist ein weiteres Problem, das vermieden wird. Gültige XML-Dateien müssen eine xmlns-Namespacedeklaration enthalten, die angibt, welcher Schemaversion sie entsprechen. So erhält RibbonX Informationen dazu, auf welche Office-Version ein bestimmtes Add-In abzielt, und ermöglicht die entsprechende Abbildung der Benutzeroberfläche trotz Änderungen, die möglicherweise von einer Version zur nächsten durchgeführt wurden. Der Mangel an Versionskontrolle und Besitz im CommandBars-Objektmodell sind zwei Hauptgründe dafür, dass ältere Add-Ins bei der Aktualisierung auf neue Office-Versionen oft Fehler verursachten und die Add-Ins-Registerkarte nicht besser zwischen dem Gewirr an Steuerelementen unterscheiden konnte, die ihr durch Objektmodellaufrufe hinzugefügt wurden.
Und schließlich verfügt XML über gute Toolunterstützung. Aufgrund der RibbonX-Schemadefinitionsdatei (XSD) können viele XML-Editoren (einschließlich Word 2007) einfach zum Erstellen von gültigen RibbonX-Benutzeroberflächen-Dateien per Drag & Drop verwendet werden.
Das CommandBars-Objektmodell lässt sich als „Push“-Modell beschreiben, bei dem die Add-Ins alle Benutzeroberflächendaten in die Office-Anwendung schieben, indem sie im Objektmodell verschiedene Eigenschaften einstellen. Jede Eigenschaft der Steuerelemente auf der Benutzeroberfläche muss beim Start ausdrücklich vom Add-In festgelegt werden, selbst wenn das Menü oder die Symbolleiste, welche dieses Steuerelement enthält, nie angezeigt wird. Wenn dazu das Laden einer großen Anzahl von Bilddateien erforderlich war, konnte dies hinsichtlich der Leistung recht zeitaufwändig sein.
RibbonX verwendet ein „Pull“-Modell, bei dem Office sich die Daten nur bei Bedarf aus dem Add-In holt. Statt Eigenschaften wie CommandBar.Name oder CommandBarButton.Picture festzulegen, stellen Add-Ins get-Rückrufe, wie z. B. getLabel oder getImage, bereit. Office ruft diese Rückrufe auf, wenn die Anwendung wissen muss, welche Beschriftung oder welches Bild ein Steuerelement hat.
Der Hauptvorteil des „Pull“-Modells liegt in der verbesserten Leistung. Bei Office 2007 ist es wahrscheinlich, dass der größte Teil der Benutzeroberfläche eines Add-Ins beim Start der Anwendung nicht sichtbar ist, besonders wenn dieses Add-In seine eigene Registerkarte auf oberster Ebene oder eine Gruppe zu der Add-In-Registerkarte hinzugefügt hat. Leistungseinbußen durch das sofortige Laden aller Bilder für diese Steuerelemente werden so vermieden. Erst wenn der Benutzer auf diese Registerkarte klickt, müssen die Bilder geladen werden. RibbonX verzögert das Aufrufen von Rückrufen soweit wie möglich, um den Aufwand für das Laden von Ressourcen während der gesamten Sitzung zu amortisieren, und sorgt dafür, dass Office-Anwendungen schnell starten, selbst wenn mehrere Add-Ins installiert sind.
Wenn Office entscheidet, wann diese Rückrufe aufgerufen werden sollen, fragen Sie sich vielleicht, wie Steuerelementeigenschaften dynamisch geändert werden können. RibbonX führt eine Zwischenspeicherung der Rückruf-Rückgabewerte durch und führt einen Rückruf erst dann durch, wenn das Add-In sie ungültig macht. Add-Ins tun dies mithilfe der Invalidate- und InvalidateControl-Methoden der IRibbonUI-Schnittstelle. Nachdem die Eigenschaften eines Steuerelements ungültig geworden sind, führt RibbonX beim nächsten Mal, wenn sie gebraucht werden, einen Rückruf durch. Wenn dieses Steuerelement zurzeit auf dem Bildschirm angezeigt wird, führt RibbonX einen Rückruf durch und aktualisiert den Wert sofort. Wird es nicht auf dem Bildschirm angezeigt, führt RibbonX den Rückruf erst dann durch, wenn es angezeigt wird. Die genauen Einzelheiten zum Implementieren von Rückruffunktionen und Durchführen von Außerkraftsetzungen in den Beispiel-Add-Ins werden später in diesem Artikel behandelt.
RibbonX stellt viele verschiedene Steuerelementtypen zum Erweitern bereit, unter anderem die in Abbildung 3 dargestellten. Nur die ersten sechs Elemente in dieser Liste waren im CommandBars-Objektmodell verfügbar – es gibt also viele neue Benutzeroberflächenoptionen für RibbonX-Add-Ins. Die vielleicht überzeugendsten neuen Steuerelementtypen sind ein splitButton, der sowohl eine Schaltfläche als auch ein Dropdown-Menü umfasst (siehe Abbildung 4), sowie ein Katalog, der erweitet werden kann und eine Auswahl an Bildern anzeigt. Beides wird in Office 2007 häufig verwendet, um Unübersichtlichkeit auf der Benutzeroberfläche zu vermeiden und visuelle Vorgänge leicht in einer Vorschau darzustellen. Add-In-Autoren sollten diese neuen Steuerelementtypen nutzen, um ihrer Benutzeroberfläche dieselbe Wirkung zu verleihen.
Figure 3 RibbonX-Steuerelemente
| RibbonX-Steuerelemente
|
| 1. button |
| 2. toggleButton |
| 3. editBox |
| 4. menu |
| 5. comboBox |
| 6. dropDown |
| 7. dialogBoxLauncher |
| 8. gallery |
| 9. splitButton |
| 10. label |
| 11. checkBox |
| 12. group |
| 13. tab |
| 14. superTip |
.gif)
Abbildung 4 SplitButton
StartFromScratch-Modus
Viele Entwickler verwenden Office als Plattform zum Erstellen eigener eigenständiger Anwendungen. Bei der Ausführung entfernen diese Anwendungen oft die gesamte Office-Benutzeroberfläche und ersetzen sie durch ihre eigene. Bei der Verwendung des CommandBars-Objektmodells gab es dafür keinen Standardmechanismus, sodass das Verfahren schwierig und fehlerhaft war.
Mit dem StartFromScratch-Modus von RibbonX hingegen erfolgt das Ausblenden der Office-Benutzeroberfläche praktisch durch das Schreiben einer XML-Zeile. Durch Einstellen von startFromScratch="true" für den <ribbon>-Stammtag geschieht Folgendes:
- Alle wichtigen Registerkarten der obersten Ebene werden ausgeblendet (aber nicht die kontextbezogenen Registerkartensätze).
- Der Inhalt der Schnellzugriffs-Symbolleiste wird ausgeblendet.
- Das Add-In wird aktiviert, sodass eigene Schaltflächen zur Schnellzugriffs-Symbolleiste hinzugefügt werden (dies ist normalerweise nicht zulässig).
- Alle Befehle im Office-Menü außer „Neu“, „Öffnen“ und „Speichern“ werden ausgeblendet.
Nach Anwendung dieser Änderungen können Add-Ins weitere Änderungen an der Benutzeroberfläche vornehmen und beispielsweise einige integrierte Registerkarten einblenden oder weitere TabSets- oder Office-Menüelemente ausblenden.
Der größte Teil der Funktion des StartFromScratch-Modus kann dupliziert werden, indem all diese Benutzeroberflächen-Elemente manuell ausgeblendet werden, doch StartFromScratch bietet gegenüber der manuellen Methode einige Vorteile. Zum einen ist es sehr viel leichter, eine Zeile XML-Code anstelle von fünfzig Zeilen zu schreiben. Zum zweiten wurde die Funktion so konzipiert, dass sie mit zukünftigen Versionen von Office kompatibel ist. Wenn die nächste Version von Word neue Registerkarten auf oberster Ebene oder neue Office-Menüelemente hinzufügt, blendet der StartFromScratch-Modus diese automatisch aus; Add-Ins, die die Benutzeroberfläche manuell ausblenden, müssen zum Ausblenden dieser neuen Elemente hingegen aktualisiert werden.
Eine weitere hervorragende Funktion des StartFromScratch-Modus besteht darin, dass der Modus auf Dokumentbasis arbeitet. Wenn der Benutzer mehrere Dokumente im MDI-Modus (Multiple Document Interface) bearbeitet, kann eins dieser Dokumente den StartFromScratch-Modus aktivieren, und die gesamte Benutzeroberfläche wird automatisch ausgeblendet oder angezeigt, wenn der Benutzer zwischen diesem Dokument und anderen hin und her wechselt. Es ist kein Code erforderlich!
Befehldeaktivierung und Zuweisen eines neuen Zwecks
Ein weiterer Vorgang, der häufig von Office-Add-Ins durchgeführt wird, ist das Deaktivieren integrierter Befehle. Mit RibbonX kann dies ebenfalls durch das Schreiben einer Zeile bewältigt werden. Entwickler können integrierte Befehle mit Zeilen wie dieser im Abschnitt <commands> ihrer XML-Datei deaktivieren:
<command idMso="Bold" enabled="false"/>
Dadurch wird die Schaltfläche „Fett“ überall auf der Benutzeroberfläche deaktiviert, was bei der Standardkonfiguration die Schriftart-Gruppe auf der Multifunktionsleiste und auch auf der MiniToolbar umfasst.
Weil dies beim CommandBars-Objektmodell nicht der Fall war, sollte bedacht werden, dass dadurch die Schaltfläche „Fett“ an beiden Orten deaktiviert wird. Add-Ins mussten jede Kopie der Schaltfläche in der gesamten Benutzeroberfläche auflisten und manuell deaktivieren, falls der Benutzer seine Symbolleisten angepasst und eine Kopie an anderer Stelle platziert hatte. Sie mussten auch Befehle anhand ihrer ID-Nummer (etwa 43) statt anhand von Namen suchen, die für Menschen lesbar sind (wie beispielsweise „Fett“). Ein getEnabled-Rückruf kann ebenfalls verwendet werden, wenn das Add-In den Befehl bedingt nur zu bestimmten Zeiten deaktivieren will.
Das XML-Element <commands> enthält auch die RibbonX-Funktion, die Befehlen einen neuen Zweck zuweist. Oft verbessern oder erweitern Add-Ins die integrierten Funktionen von Office, übernehmen vorhandene Benutzeroberflächen-Schaltflächen und weisen ihnen einen neuen Zweck zu. Alternativ schränken IT-Manager Funktionen durch Zuweisung eines neuen Zwecks bisweilen ein, indem beispielsweise bei Klicken auf die Schaltfläche „Drucken“ ein Kennwortdialogfeld angezeigt wird.
Jeder Schaltfläche, die bei Anklicken eine Aktion durchführt, kann mithilfe von RibbonX ein neuer Zweck zugewiesen werden (obwohl dies bei komplizierteren Steuerelementtypen wie z. B. Katalogen oder Kombinationsfeldern nicht möglich ist). Hier ein Beispiel des erforderlichen XML-Codes, um der Schaltfläche „Speichern“ einen neuen Zweck zuzuweisen:
<command idMso="Save" onAction="MySaveFunction"/>
Bei Klicken auf „Speichern“ wird die MySaveFunction des Add-Ins ausgeführt, sodass das Add-In seine eigenen Aktionen durchführen und entscheiden kann, ob die integrierte Funktion „Speichern“ ausgeführt werden soll.
Auch hier wird wieder allen Kopien der Schaltfläche „Speichern“ mit dieser einen Zeile XML-Code der neue Zweck zugewiesen (sowohl im Office-Menü als auch auf der Schnellzugriffs-Symbolleiste), und wenn ein einzelnes Dokument den neuen Zweck zuweist, gilt dies nicht für andere, ebenfalls geöffnete Dokumente (es sei denn, das Dokument wurde als globale Vorlage oder Add-In geladen).
Bedarfsgesteuertes Laden
Ein Problem von Office-Add-Ins besteht darin, dass ihre DLLS oft eine Weile zum Starten brauchen, besonders wenn sie in verwaltetem Code geschrieben wurden und die CLR-Informationen (Common Language Runtime) noch nicht geladen wurden. Benutzer, bei denen mehrere Add-Ins installiert sind, müssen bei jedem Starten einer Office-Anwendung mit einer beträchtlichen Leistungseinbuße rechnen. Das Ironische daran ist, dass der Benutzer wahrscheinlich die meisten Funktionen der Add-Ins nicht in allen Sitzungen nutzt – trotzdem bezahlt er mit der Leistungseinbuße einen Preis dafür.
Da Verlangsamungen sowohl auf Office als auch auf die Add-Ins ein schlechtes Licht werfen, stellt Office eine Funktion für COM-Add-Ins bereit, die als bedarfsgesteuertes Laden bezeichnet wird. Diese Funktion wurde in Office 2007 aktualisiert und erweitert, sodass sie nun auch RibbonX-Unterstützung umfasst. Nachstehend wird der Prozess dargestellt. Der Add-In-Autor belegt den LoadBehavior-Registrierungsschlüssel des Add-Ins mit ConnectFirstTime (16). Nach dem ersten Startvorgang der Anwendung nach Installation des Add-Ins wird das Add-In gestartet. Office fragt den RibbonX-XML-Code des Add-Ins ab und führt eine Zwischenspeicherung auf der Festplatte durch. RibbonX ruft dann alle Get-Rückrufe des Add-Ins auf, um alle Bilder zu laden und eine Zwischenspeicherung des Anfangszustands des Add-Ins durchzuführen.
Beim Herunterfahren wird der Registrierungsschlüssel des Add-Ins zu DemandLoad geändert. Bei anschließenden Startvorgängen wird das Add-In nicht gestartet, aber seine RibbonX-Benutzeroberfläche wird so angezeigt, als ob es geladen worden wäre. Sobald der Benutzer auf eine Schaltfläche des Add-Ins klickt, wird das Add-In geladen, um den Befehl des Benutzers auszuführen.
Das bedarfsgesteuerte Laden ist für den Endbenutzer transparent, und außer dem Einstellen des Registrierungsschlüssels müssen die Entwickler keine weitere Arbeit leisten (Man vergleiche dies mit dem schwierigen Einrichten von <!ProgID>-Zeichenfolgen, um das bedarfsgesteuerte Laden mit dem CommandBars-Objektmodell zu verwenden.) Natürlich ist das bedarfsgesteuerte Laden nicht für jedes Add-In nützlich. Aber es sollte für die Mehrzahl von Add-Ins von Vorteil sein, die nur eine Schaltfläche oder ein Menüelement zur Benutzeroberfläche hinzufügen und ihre Funktion dann beim Anklicken des entsprechenden Elements aktivieren. Kompliziertere Add-Ins, bei denen ausgeklügelter Code ausgeführt werden muss, bevor der Benutzer mit ihrer Benutzeroberfläche kommuniziert, können das bedarfsgesteuerte Laden jedoch nicht nutzen, da sie geladen sein müssen, um Code auszuführen.
Aktualisieren einer Word-Vorlage auf RibbonX
Nachdem alle wichtigen Funktionen von RibbonX vorgestellt wurden, werde ich nun einige Einzelheiten anhand von Beispiel-Add-Ins und Codeausschnitten erläutern. Zuerst geht es um ein Szenario, dem viele Entwickler begegnen werden, wenn sie auf Office 2007 umsteigen: das Aktualisieren eines älteren Add-Ins von CommandBars auf RibbonX.
Das Add-In, das ich aktualisieren werde, ist eine recht einfache Word-Vorlage (.dot), deren Funktion darin besteht, leere Seiten in ein juristisches Dokument zusammen mit dem üblichen (und an sich widersprüchlichen) Text „Diese Seite wurde absichtlich leer gelassen“ einzufügen.
Das Add-In wird mit einer Schaltfläche im Menü „Einfügen“ in den mit dem Dokument verknüpften CommandBars implementiert. Die OnAction-Eigenschaft der Schaltfläche ist mit InsertBlankPage belegt, wobei es sich um ein VBA-Makro (Visual Basic
® for Applications) handelt, das folgenden Code enthält:
Sub InsertBlankPage()
' Insert a blank page
Selection.InsertBreak Type:=wdPageBreak
Selection.ParagraphFormat.Alignment = wdAlignParagraphCenter
Selection.Font.Size = 14
Selection.Font.Color = wdColorGray50
Selection.Font.Name = "Arial Black"
Selection.TypeText Text:="This Page Intentionally Left Blank"
Selection.InsertBreak Type:=wdPageBreak
End Sub
Dieser ist offensichtlich nicht besonders schwierig, ist aber gut zu Demonstrationszwecken geeignet. Die Datei kann von der MSDN®Magazin-Website heruntergeladen werden. Sie können sie mithilfe des Dialogfelds „Vorlagen und Add-Ins“ als globale Vorlage installieren.
Der erste Schritt bei der Aktualisierung eines älteren CommandBar-Add-Ins auf die neue Office 2007-Benutzeroberfläche besteht in der Abbildung der alten Benutzeroberfläche auf das neue Modell. Da alle Symbolleisten und Menüs durch die Multifunktionsleiste ersetzt werden, ist nicht sofort ersichtlich, wo die Benutzeroberfläche des Add-Ins am besten hin passt.
Bevor Sie sich an die Arbeit begeben, sollten Sie sich zuerst folgende Frage stellen: „Muss dieses Add-In überhaupt aktualisiert werden?“ Wenn das Budget begrenzt ist, könnte die Antwort in vielen Fällen Nein lauten. Wenn Sie das Add-In in Word 2007 laden, funktioniert es in der Add-In-Registerkarte problemlos (siehe Abbildung 5).
.gif)
Abbildung 5 Älteres Add-In
An seiner Funktion ist im Grunde nichts auszusetzen, aber möglicherweise missfällt es Ihnen, dass es sich zusammen mit all den anderen älteren Add-Ins in der Gruppe „Menübefehle“ befindet und nicht die neuen Funktionen von RibbonX nutzt. Zudem wäre es keine besonders gute Demo, wenn ich hier einfach Schluss machen würde. Lassen Sie uns daher fortfahren.
Da das Add-In Seiten in ein Dokument einfügt, wäre die Benutzeroberfläche wahrscheinlich gut auf der Registerkarte „Einfügen“ untergebracht. Wenn das Add-In das Dokument als Ganzes bearbeiten würde, könnten Sie seine Benutzeroberfläche im Office-Menü unterbringen. Wenn es in der vorhandenen Benutzeroberfläche keine geeignete Stelle gibt, wäre eine benutzerdefinierte Gruppe auf der Add-Ins-Registerkarte das Beste (statt eine ganze Registerkarte mit nur einer Schaltfläche zu erstellen).
Die integrierte Registerkarte „Einfügen“ für Word enthält eine Gruppe für das Einfügen von Seiten, die sogar schon eine Schaltfläche für das Einfügen leerer Seiten umfasst (dies ist eine neue Funktion in Office 2007). Da das ältere Add-In auch den Platzhaltertext „Absichtlich leer“ einfügt, sollte es von der integrierten Funktion unterschieden werden können. Wir wollen eine benutzerdefinierte Gruppe mit der Bezeichnung „Juristische Seiten“ neben der anderen Gruppe und eine große Schaltfläche mit einem aufschlussreichen Symbol hinzufügen. Abbildung 6 zeigt, wie das Ganze aussehen soll, wenn es fertig ist.
.gif)
Abbildung 6 Add-In „Seite einfügen“
Beim nächsten Schritt geht es um das Erstellen der XML-Datei, die für das gewünschte Ergebnis sorgt. Bei Demos geht es oft am schnellsten, wenn man mit dem fertigen Produkt beginnt und dann erläutert, wie es funktioniert. In diesem Sinne zeigt Abbildung 7 die fertige XML-Datei.
Figure 7 InsertBlankPage-XML-Code
<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
<ribbon>
<tabs>
<tab idMso="TabInsert">
<group id="LegalGroup" label="Legal Pages"
insertAfterMso="GroupInsertPages">
<button id="BlankPageButton" label="Intentionally Blank Page"
size="large" image="BlankIcon"/>
</group>
</tab>
</tabs>
</ribbon>
</customUI>
Wie Sie sehen, ist diese recht unkompliziert. Das Stammtag ist <customUI> und gibt als Ausgangspunkt den Office 2007-RibbonX-XML-Namespace an. Dann folgen eine Reihe von Tags, die die Struktur der Benutzeroberfläche widerspiegeln: Multifunktionsleiste > Registerkarten > Registerkarte > Gruppe > Schaltfläche.
Das erste interessante Element ist die Eigenschaft idMso="TabInsert" auf dem Tag <tab>. Alle Steuerelemente in der XML-Datei müssen ID-Eigenschaften zu ihrer Identifizierung haben. Integrierte Steuerelemente zeigen mit idMso, dass es sich um Office-Steuerelemente handelt, sodass sie von benutzerdefinierten Steuerelementen unterschieden werden können, welche die id-Eigenschaft verwenden. Die XML-Datei sagt damit praktisch, dass nach der integrierten Registerkarte „Einfügen“ gesucht und innerhalb der Registerkarte eine benutzerdefinierte Gruppe erstellt werden soll. Die Eigenschaft insertAfterMso="GroupInsertPages" bedeutet, dass diese Gruppe nach der integrierten Gruppe „Seiten“ eingefügt werden soll. Schließlich bedeutet button id="BlankPageButton", dass eine benutzerdefinierte Schaltfläche innerhalb der Gruppe erstellt werden soll.
In diesem Beispiel sind die Beschriftungen der Gruppe und Schaltfläche in der XML-Datei statisch angegeben, sodass sie sich nie ändern können. Das ist in diesem Fall in Ordnung so, aber wenn Sie Beschriftungen (z. B. für Lokalisierungszwecke) dynamisch ändern wollen, könnten Sie stattdessen die getLabel-Eigenschaft verwenden, um eine Funktion anzugeben, die die Beschriftung zurückgibt.
Der letzte interessante Teil ist die Eigenschaft image="BlankIcon". Diese weist RibbonX an, in der Word-Vorlagendatei nach einem Bild mit dieser ID zu suchen. Dieses Bild muss zu demselben Zeitpunkt in die Datei eingefügt werden, wenn Sie den XML-Code einfügen.
Hinzufügen von XML-Code und Bildern
Die verknüpfte RibbonX-XML-Datei wird nur im neuen Dateiformat für Office 2007 unterstützt, daher müssen Sie als erstes die .dot-Datei öffnen und sie als .dotm-Datei speichern (das hinzugefügte „m“ bedeutet, dass die Datei Makros enthält). Anschließend benennen Sie die Datei mit einer .zip-Erweiterung um und öffnen sie, um den Inhalt zu prüfen, wie in Abbildung 8 dargestellt.
.gif)
Abbildung 8 In der Dokumentvorlage (Klicken Sie zum Vergrößern auf das Bild)
Die Einzelheiten des Open XML-Dateiformats sind Thema für einen anderen Artikel. Für unsere Zwecke reicht es zu wissen, dass es sich bei den Dateien im Wesentlichen um komprimierte Pakete handelt, die mehrere Dateien enthalten, welche sich auf unterschiedliche Weise aufeinander beziehen. In diesem Beispiel ist document.xml das eigentliche Word-Dokument, das mit verschiedenen Dingen wie z. B. Stilinformationen, dem VBA-Code und den verknüpften CommandBars verbunden ist. Da die Datei nicht mehr über die verknüpften CommandBars verfügen soll, löschen wir die attachedToolbars.bin-Datei aus der .zip-Datei und packen sie dann wieder.
Die .zip-Datei könnte manuell bearbeitet werden, um den RibbonX-XML-Code und das Symbolbild einzufügen, aber es ist viel einfacher, ein Tool zu verwenden, und das wollen wir tun. Bei
openxmldeveloper.org gibt es eine Anzahl von Tools für das Open XML-Dateiformat. Das Tool, das wir brauchen, heißt
Custom UI Editor.
Custom UI Editor ist ein praktisches kleines Tool zum Einfügen von RibbonX-XML-Code und den dazugehörigen Bildern in Dateien im Open XML-Format. Öffnen Sie die .dotm-Datei damit, und fügen Sie dann den XML-Code und das Bild ein (siehe Abbildung 9). Speichern Sie die Datei. Wenn Sie neugierig sind, können Sie das Ganze wieder als .zip-Datei öffnen. Sie werden dann sehen, dass das Tool die XML-Datei unter customUI\customUI.xml und das Bild unter customUI\images\BlankIcon.png erstellt hat. Es wurden auch einige rels-Beziehungen geändert, so dass diese auf die neuen Dateien verweisen.
.gif)
Abbildung 9 Bearbeiten der Vorlage (Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie nun die Datei in Word öffnen, sehen Sie die neue Schaltfläche, doch es geschieht nichts, wenn auf sie geklickt wird. Das ist nur logisch, da Sie noch nicht angegeben haben, welches Makro aufgerufen werden soll. Dazu fügen Sie die hier in Rot dargestellten Eigenschaften der XML-Datei hinzu:
<button id="BlankPageButton" label="Intentionally Blank Page"
size="large" image="BlankIcon"
onAction="RibbonXOnAction" tag="InsertBlankPage" />
Es mag anfänglich merkwürdig scheinen, ein neues Makro mit der Bezeichnung RibbonXOnAction einzuführen, statt einfach das Makro InsertBlankPage wiederzuverwenden. Der Grund, warum ich dies getan habe, ist der, dass RibbonXOnAction-Makros andere Signaturen als ihre CommandBar-Gegenstücke haben. Wenn Sie viele Makros haben, müssten Sie diese alle manuell ändern, was zeitaufwändig und fehleranfällig sein könnte. Zudem würde dann der Code nicht mehr eingehalten, sodass er auf vorherigen Versionen von Office nicht ausgeführt werden kann.
Sie können beide Probleme umgehen, indem Sie das neue RibbonX-Makro einfach die alten CommandBar-Makros aufrufen lassen. Und hier kommt die tag-Eigenschaft ins Spiel: Es handelt sich dabei um eine Zeichenfolgeeigenschaft, die in der Benutzeroberfläche nicht verwendet wird, aber an den Code des Add-Ins zur dortigen Verwendung übergeben wird. Hier sehen Sie, wie sie im RibbonXOnAction-Makro verwendet wird, das Sie in ein neues VBA-Modul einfügen können:
Sub RibbonXOnAction(button As IRibbonControl)
Application.Run button.Tag
End Sub
Das RibbonX-OnAction-Makro erfordert ein IRibbonControl-Objekt als Parameter, das die Schaltfläche darstellt, auf die geklickt wurde. In CommandBars hatten OnAction-Makros keine Parameter, sodass es bisweilen schwierig zu ermitteln war, auf welche Schaltfläche geklickt wurde. Das IRibbonControl-Objekt stellt ID- und Tag-Eigenschaften bereit, um dieses Problem in RibbonX zu lösen.
Wenn dieses Makro eingerichtet ist, funktioniert die neue Schaltfläche! Zum Aktualisieren des Codes dieses Add-Ins zum Ausführen mit RibbonX war nicht viel nötig: ein neues einzeiliges Makro und keine Änderungen am vorhandenen Code. Einfach.
Ein COM-Add-In für Excel
Beim zweiten Beispiel wird es ein wenig komplizierter, da wir ein COM-Add-In für Excel® schreiben. Das Timecard-Add-In wird eine kleine LOB-Anwendung (Line-of-Business) zum Ausfüllen und Senden von Zeiterfassungskarten sein. Hier werden nur Codeausschnitte gezeigt, doch der vollständige Quellcode ist als Download verfügbar.
Beim ersten Schritt geht es wieder um die Frage, was für eine Benutzeroberfläche erforderlich ist. Das Add-In ermöglicht es Benutzern, Zeiterfassungskarten zu erstellen, diese zu bearbeiten und zu senden. Da die zunächst einzige benötigte Benutzeroberfläche zur Zeiterfassung eine Schaltfläche mit der Bezeichnung „New Timecard“ (Neue Zeiterfassungskarte) ist, stellen Sie diese einzeln in das Office-Menü (siehe Abbildung 10).
.gif)
Abbildung 10 Eine neue Schaltfläche
Nachdem auf die Schaltfläche „New Timecard“ (Neue Zeiterfassungskarte) geklickt (oder eine vorhandene Zeiterfassungskarte geöffnet) wurde, zeigen Sie den Rest der Benutzeroberfläche zur Zeiterfassung auf einer benutzerdefinierten Registerkarte an. Da verschiedene Excel-Registerkarten wie z. B. „Seitenlayout“, „Formeln“, „Überprüfen“ und „Daten“ für das Ausfüllen von Zeiterfassungskarten nicht relevant sind, blenden Sie diese zur selben Zeit aus (siehe Abbildung 11).
.gif)
Abbildung 11 Eine benutzerdefinierte Multifunktionsleisten-Registerkarte für Zeiterfassungskarten (Klicken Sie zum Vergrößern auf das Bild)
Die Benutzeroberfläche zur Zeiterfassung ist viel komplizierter als jene des vorhergehenden Add-Ins, was auch für den zu ihrer Erstellung verwendeten XML-Code gilt, wie Abbildung 12 zeigt. Zur Verwendung von RibbonX müssen COM-Add-Ins zunächst die IRibbonExtensibility-Schnittstelle implementieren. Dank der IntelliSense®-Funktion von Visual Studio® ist dies nicht besonders schwer. Erstellen Sie in Visual Studio ein Add-In, indem Sie „Neues Projekt“ auswählen, die Kategorie „Andere Projekttypen“ aufrufen und im Abschnitt „Erweiterungen“ die Option „Gemeinsames Add-In“ auswählen.
Figure 12 Timecard-XML-Code
<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui"
onLoad="OnLoad" loadImage="LoadImage">
<ribbon>
<officeMenu>
<button id="NewTimecard" insertAfterMso="FileNew"
label="New Timecard" imageMso="StartAfterPrevious"
onAction="NewTimecard" />
</officeMenu>
<tabs>
<tab id="TimecardTab" label="Timecard"
getVisible="IsCustomTabVisible">
<group id="EditingTools" label="Editing Tools">
<button id="ClearTimecard" label="Clear Timecard" size="large"
imageMso="TableDeleteRowsAndColumnsMenuWord"
onAction="ClearTimecard"/>
<button id="InsertDay" label="Insert New Day" size="large"
imageMso="CellsInsertDialog" onAction="InsertNewDay"/>
<button id="CalculateTotal" label="Calculate Hours Worked"
size="large" imageMso="SlideShowRehearseTimings"
onAction="CalculateHours"/>
</group>
<group id="WageTools" label="Wage Tools">
<editBox id="Wage" label="Hourly wage:"
image="dollar1.png" onChange="OnWageChanged"
getText="GetWage"/>
<editBox id="Overtime" label="Overtime bonus:"
image="dollar2.png" onChange="OnOvertimeChanged"
getText="GetOvertime"/>
<button id="CalculatePay" label="Calculate Pay"
size="large" imageMso="AcceptInvitation"
onAction="CalculatePay"/>
</group>
<group id="SubmissionTools" label="Submission Tools">
<button id="SignTimecard" label="Sign Timecard"
size="large" image="signature.png"
onAction="SignTimecard"/>
<button id="SubmitTimecard" label="Submit Timecard"
size="large" image="submit.png"
onAction="SubmitTimecard" getEnabled="IsTimecardSigned"
screentip="Make sure to sign your timecard before
submitting" />
</group>
</tab>
<tab idMso="TabPageLayoutExcel" getVisible="IsBuiltinTabVisible"/>
<tab idMso="TabData" getVisible="IsBuiltinTabVisible" />
<tab idMso="TabReview" getVisible="IsBuiltinTabVisible" />
<tab idMso="TabFormulas" getVisible="IsBuiltinTabVisible" />
</tabs>
</ribbon>
</customUI>
Klicken Sie durch den Dialog und anschließend durch den Assistenten. Sie müssen verschiedene Optionen wie z. B. Office-Anwendungen, in denen Ihr Add-In installiert werden soll, und die zu verwendende Programmiersprache auswählen. Für dieses Beispiel habe ich mich für C# entschieden.
Nach Erstellen Ihres Add-Ins wird die Connect-Klasse angezeigt, die das Standard-COM-Add-In IDTExtensibility2-Schnittstelle implementiert. Dies ist das Objekt, in dem Sie IRibbonExtensibility implementieren müssen. Fügen Sie diese Schnittstelle hinzu, und lassen Sie ihre Methoden automatisch durch Visual Studio implementieren. Das Ergebnis sollte etwa so aussehen:
using Office = Microsoft.Office.Core;
[GuidAttribute("E8407539-C642-43BB-8FCB-2E27A46179DE"),
ProgId("TimecardAddin.Connect")]
public class Connect : Object, Extensibility.IDTExtensibility2,
Office.IRibbonExtensibility
{
public string GetCustomUI(string RibbonID)
{
throw new Exception("Not implemented.");
}
// IDTExtensibility methods
}
Die einzige Methode von IRibbonExtensibility ist GetCustomUI, die den RibbonX-XML-Code als Zeichenfolge zurückgibt. Sie erfordert auch einen RibbonID-Parameter, bei dem es sich um eine Zeichenfolge wie „Microsoft.Word.Document“ oder „Microsoft.Excel.Workbook“ handelt und der hauptsächlich beim Schreiben von Add-Ins nützlich ist, die in mehreren Anwendungen oder in Anwendungen mit mehreren Arten von Multifunktionsleisten (wie z. B. Microsoft Outlook) ausgeführt werden.
Wenn Sie dem Projekt die XML-Datei als eingebettete Ressource mit der Bezeichnung customui.xml hinzufügen, können Sie diese von GetCustomUI zurückgeben lassen, indem Sie folgenden Code verwenden:
public string GetCustomUI(string RibbonID)
{
Assembly assembly = Assembly.GetExecutingAssembly();
using(Stream stream = assembly.GetManifestResourceStream(
"TimecardAddin.customui.xml"))
{
return new StreamReader(stream).ReadToEnd();
}
}
Nun können Sie das Add-In erstellen und installieren. Nach dem Starten von Excel sollte die angepasste Benutzeroberfläche angezeigt werden, wobei die benutzerdefinierten Bilder noch nicht geladen sind und nichts geschieht, wenn auf die Schaltflächen geklickt wird.
Alle Rückruffunktionen, auf die der XML-Code verweist, werden nicht aufgerufen, da sie noch nicht implementiert wurden. Wenn die Option „Fehler in Benutzeroberflächen in Add-Ins anzeigen“ im Abschnitt „Erweitert“ des Dialogfelds „Anwendungsoptionen“ aktiviert ist, wird eine Folge von Fehlermeldungen über die fehlgeschlagenen Rückrufe angezeigt. Stellen Sie sicher, dass Sie diese Option beim Entwickeln von RibbonX-Add-Ins aktivieren. Die Option aktiviert einen umfangreichen Satz von Fehlermeldungen, die Sie auf Fehler in Ihrem Add-In hinweisen. Die zuerst angezeigte Fehlermeldung gibt an, dass der „onLoad“-Rückruf nicht ausgeführt wurde. Daher soll dieser als erster implementiert werden.
Implementieren der Rückruffunktionen
Das Stammtag <customUI> in der Multifunktionsleiste hat einen optionalen onLoad-Rückruf, den Add-Ins implementieren können, um einen Verweis auf das IRibbonUI-Objekt zu erhalten. Durch Verwenden des IRibbonUI-Objekts verlieren alle zwischengespeicherten Rückruf-Rückgabewerte ihre Gültigkeit, wenn sich der Status der Benutzeroberfläche des Add-Ins ändern muss. Ich werde gleich auf die Einzelheiten eingehen, doch vorerst bringen Sie es in einer Mitgliedsvariablen unter. Fügen Sie diesen Code der Connect-Klasse hinzu:
Office.IRibbonUI m_Ribbon;
public void OnLoad(Office.IRibbonUI ribbon)
{
m_Ribbon = ribbon;
}
Ein weiterer optionaler Rückruf im <customUI>-Tag ist loadImage, mit dessen Hilfe COM-Add-Ins die Symbole für ihre Steuerelemente laden. Hier kommen die image="dollar1.png"- Zeilen in der XML-Datei ins Spiel. Für jede in einer Bildeigenschaft angegebene Zeichenfolge ruft RibbonX loadImage zum Laden des betreffenden Bilds auf.
Bilder können ganz nach Belieben des Add-Ins gespeichert werden, doch in diesem Beispiel wollen wir die Bilder wie bei der XML-Datei als eingebettete Ressourcen hinzufügen. Angenommen, Sie haben dollar1.png als Ressource in der TimecardAddin-Assembly hinzugefügt, wird der loadImage-Rückruf folgendermaßen implementiert:
public Bitmap LoadImage(string imageName)
{
Assembly assembly = Assembly.GetExecutingAssembly();
Stream stream = assembly.GetManifestResourceStream(
"TimecardAddin." + imageName);
return new Bitmap(stream);
}
Diese Funktion weist einige interessante Dinge auf. Zum einen gibt sie ein System.Drawing.Bitmap-Objekt als Bild zurück. Die Unterstützung von System.Drawing.Bitmap ist neu in Office 2007 mit RibbonX und ist die einfachste und empfohlene Möglichkeit, Bilder für verwaltete Add-Ins zurückzugeben. Nicht verwaltete Add-Ins (C++ und Visual Basic 6.0) können IPictureDisp-Objekte für ihre Bilder zurückgeben, wobei es sich um dasselbe Format handelt, das in CommandBars verwendet wurde.
Zweitens ist zu festzuhalten, dass nur ein Bild zurückgegeben wird, das sowohl die Bitmap-Daten als auch die Transparenzendaten enthält. Es ist also nicht mehr erforderlich, zwei separate Bild- und Maskensymbole für Ihre Office-Add-Ins zu erstellen! Mit RibbonX unterstützt Office jetzt vollständige 32-Bit-Symbole mit Alphakanälen. Derzeit verfügt das PNG-Format über den besten Toolsupport für Alphakanäle und ist das empfohlene Format für Ihre RibbonX-Symbole.
Der nächste Rückrufsatz, den Sie implementieren müssen, sind die getVisible-Rückrufe auf den integrierten Registerkarten und auf der benutzerdefinierten Registerkarte. Alle integrierten Registerkarten verwenden IsBuiltinTabVisible, während die benutzerdefinierte Registerkarte IsCustomTabVisible verwendet, da diese beiden Funktionen entgegengesetzte Werte zurückgeben müssen (die integrierten Registerkarten sollten ausgeblendet werden, wenn eine Zeiterfassungskarte bearbeitet wird, da dann die benutzerdefinierte Registerkarte angezeigt werden soll).
Das Add-In kann verfolgen, ob es sich bei einer bestimmten Excel-Arbeitsmappe um eine Zeiterfassungskarte handelt, indem die Category-Eigenschaft der Datei auf „Timecard“ gesetzt wird. Dateien ohne diese Eigenschaft werden ignoriert.
Die Funktionen IsBuiltinTabVisible und IsCustomTabVisible verwenden beide die Hilfsfunktion IsTimecard:
public bool IsCustomTabVisible(Office.IRibbonControl tab) {
return IsTimecard(tab.Context as Excel.Window);
}
public bool IsBuiltinTabVisible(Office.IRibbonControl tab) {
return !IsTimecard(tab.Context as Excel.Window);
}
private bool IsTimecard(Excel.Window window)
{
if (null == window) return false;
Excel.Workbook workbook = (Excel.Workbook)window.Parent;
Office.DocumentProperties properties =
(Office.DocumentProperties)workbook.BuiltinDocumentProperties;
Office.DocumentProperty category = properties["Category"];
return (null != category && null != category.Value &&
category.Value.Equals("Timecard"));
}
Dieser Code verwendet die Context-Eigenschaft von IRibbonControl, die an RibbonX-Rückrufe übergeben wird. Die Context-Eigenschaft entspricht in den meisten Office-Anwendungen dem Fensterobjekt. (Access hat keine Fensterobjekte, sodass der Wert dort NULL ist, und in Outlook entspricht sie den Inspektorobjekten). Add-Ins sollten das Fensterobjekt verwenden, um feststellen, auf welches Dokument dieser RibbonX-Rückruf verweist, da es nicht immer mit der Application.ActiveDocument-Eigenschaft identisch ist. Das Fensterobjekt kann auch verwendet werden, um zwischen zwei verschiedenen Fenstern zu unterscheiden, in denen dasselbe Dokument angezeigt wird.
Vom Fensterobjekt können Sie das Arbeitsmappenobjekt abrufen und von dort die Category-Eigenschaft, um zu prüfen, ob diese „Timecard“ lautet.
getVisible-Rückrufwerte ungültig machen
Wenn Sie Excel jetzt starten, sehen Sie, dass die benutzerdefinierte Registerkarte ausgeblendet wird und die integrierten Registerkarten angezeigt werden. Dies ist richtig so, da es sich beim Standarddokument nicht um eine Zeiterfassungskarte handelt. Doch wenn Sie ein Zeiterfassungskarten-Dokument öffnen, werden die Registerkarten nicht angezeigt. Woran liegt das?
Aus Leistungsgründen führt RibbonX eine Zwischenspeicherung der Rückgabewerte durch, die von den get-Rückrufen eingehen. Wenn dies nicht der Fall wäre, würden ständig Rückrufe zum Add-In stattfinden, für den Fall, dass an der Benutzeroberfläche irgendein ein Wechsel vorgenommen werden soll. Das Add-In muss Office mitteilen, wann es seine Benutzeroberfläche ändern will.
Hier kommt das bereits erläuterte IRibbonUI-Objekt ins Spiel. Es enthält zwei Methoden: Invalidate und InvalidateControl. Die Invalidate-Methode macht alle zwischengespeicherten Rückrufe ungültig, während die InvalidateControl-Methode einen Steuerelement-ID-Parameter verwendet und die zwischengespeicherten Rückrufe nur für ein bestimmtes benutzerdefiniertes Steuerelement ungültig macht.
Sie müssen jedes Mal, wenn in Excel ein Dokumentwechsel stattfindet, die getVisible-Rückrufwerte der Registerkarte ungültig machen, da dies der Zeitpunkt ist, zu dem die Benutzeroberfläche möglicherweise angezeigt werden muss. Sie können dafür das von Excel bereitgestellte WorkbookActivate-Ereignis verwenden. Fügen Sie in der OnStartupComplete-Methode für dieses Ereignis einen Handler hinzu:
public void OnStartupComplete(ref System.Array custom)
{
excelApplication.WorkbookActivate +=
new Excel.AppEvents_WorkbookActivateEventHandler(
OnWorkbookActivate);
}
void OnWorkbookActivate(Excel.Workbook Wb)
{
// the custom tab might need to become visible on workbook
// switch, so invalidate the cached getVisible values
m_Ribbon.Invalidate();
}
Glücklicherweise kann Visual Studio IntelliSense den Ereignishandler automatis