Teil 3: VBA-Makros in OpenOffice.org

Microsoft Office und OpenOffice verfügen über Programmierschnittstellen für Makros. Als Programmiersprache kommt eine BASIC-Variante zum Einsatz, die im Fall von Microsoft Office Visual Basic for Applications (VBA) im anderen Fall OpenOffice.org Basic oder StarBasic heißt. Beide verfügen über einen nahezu identischen Sprachumfang, greifen aber auf völlig unterschiedliche Art auf Objekte und Eigenschaften zu. VBA-Entwickler haben es mit einer zwar umfangreichen, aber dennoch relativ leicht zu durchschauenden Ansammlung von Anwendungsobjekten zu tun. In diesem Objektmodell repräsentiert jedes Objekt genau ein Element des jeweiligen Programms.

Das ActiveDocument-Objekt etwa steht für das aktuelle Dokument in Word und verfügt über programmierbare Eigenschaften und Methoden, mit denen der Entwickler auf das Dokument zugreifen kann. Bei der OpenOffice-Programmierung gibt es keine Objektmodelle, die die Bestandteile einer Anwendung eins zu eins widerspiegeln. Stattdessen hat man es mit der komplexen und anwendungsübergreifenden Programmierschnittstelle Universal Network Objects (UNO) zu tun. Solche UNO-Objekte besitzen zwar auch Eigenschaften, die sich auslesen und zumeist ändern lassen, sowie Methoden, die man aufrufen kann, um eine bestimmte Aktion auszulösen. Der programmierte Zugriff darauf unterscheidet sich jedoch grundlegend von dem bei VBA. Wegen der großen konzeptionellen Unterschiede gibt es kein Makro, das nach der unveränderten Übernahme im jeweils anderen Büropaket noch funktioniert.

Kaum was erreicht

Im konvertierten Kalkulationsdokument waren die Ergebnisse noch ernüchternder. Beim ersten Makro meckerte StarOffice über die unbekannte FormulaLocal-Eigenschaft zum Einfügen der deutschsprachigen Rechenformel SUMME(). Hätte man stattdessen die Eigenschaft Formula verwendet und ihr die englische Version SUM() der Additionsformel zugewiesen, wäre das Makro durchgelaufen. Beim 3D-Diagramm-Makro störte sich StarOffice ein weiteres Mal an der unbekannten ChartType-Anweisung. Dem Monatskalender-Makro wurde das Einfügen des Makrostartbefehls in die Menüleiste von Calc verweigert.

Und darüber hinaus scheiterte das Makro ? ebenso wie sein von Umlauten befreiter "Blaetterwald"-Kollege - am Aufruf des Userform-Dialogfelds. Das lag aber nicht etwa daran, dass die Userforms nicht in StarBasic-Dialoge umgewandelt worden wären - das macht jede OpenOffice-Version auch ohne Konverterhilfe. Stattdessen war dem Compiler lediglich die Show-Methode zum Aufruf der Dialoge unbekannt. Das ist etwa so, als hätte man die kunstvolle Kopie eines Ferraris erhalten, käme aber nicht hinein, weil der Schlüssel fehlt...

Bei OxygenOffice ist der von Novell entwickelte Makrokonverter schon vollständig eingebaut. Für den Anwender bedeutet das, dass er im Vergleich zur Sun-Lösung auf die zeitraubende Analyse und Konvertierung verzichten kann. Ein Blick in den Makroquellcode zeigt, dass dieser nicht einfach auskommentiert wird, wie es bei normalen OpenOffice-Editionen der Fall ist, sondern vollständig und im originalen VBA-Wortlaut erhalten ist. Es findet also ebenso wie bei Sun keine Übersetzung von VBA- in UNO-Code statt. Stattdessen bemüht sich der Novell-Konverter um eine möglichst akkurate Nachbildung der Microsoft-Office-Objekte - was ihm jedoch nur sehr unvollkommen gelingt.

Das zeigte sich eindrucksvoll an unserem Testdokument, wo nach dem Einlesen in Calc keines der vier Makros mehr funktionierte. Überall hatte der Interpreter etwas zu meckern. Die Fehlermeldung lautete fast unisono "Eigenschaft oder Methode nicht gefunden". Beim Blaetterwald-Makro wurde die Caption-Eigenschaft der Userform als unbekannt gegeißelt. Das passierte auch bei der Show-Methode, so dass die Userform - ebenso wie im Fall des Monatskalender-Makros - gar nicht erst auf dem Bildschirm erschien.

Fazit

Das Testergebnis enttäuscht. In der Zukunft dürften sich die Erfolgschancen jedoch deutlich verbessern. Denn Sun, Novell und die Open-Source-Community planen eine Bündelung ihrer Anstrengungen. Der Konverter soll wie das Novell-Tool funktionieren, aber ungleich leistungsfähiger sein.