Teil 2: VBA-Makros in OpenOffice.org

Beim Test des Macro Migration Wizard kamen zwei Word-2003-Dokumente mit unterschiedlich anspruchsvollen Makros zum Einsatz. Das erste Dokument (wdRecMakros.doc) enthielt ausschließlich einfache Makros, die mit dem Makrorecorder von Word aufgezeichnet wurden. Das erste Makro schrieb einen Satz in das Dokument und versah die einzelnen Wörter mit unterschiedlichen Formatierungen. Makro Nummer zwei ersetzte jedes Vorkommen eines Wortes durch ein anderes. Das dritte Makro generierte eine Tabelle, fügte zwei Zahlen darin ein und addierte deren Werte mit Hilfe einer Feldformel. Das vierte Makro beschränkte sich auf das Einfügen eines Bildes in das Dokument. Das letzte Makro versah das Dokument mit einer dreispaltigen Formatierung und fügte dem File eine Kopfzeile hinzu, die den Dateinamen, das Erstellungsdatum sowie die Seitenzahl als Feldfunktionen enthielt.

Das zweite Testdokument (wdProg-Makros.doc) enthielt nur handgeschriebene VBA-Makros mittleren Schwierigkeitsgrads. Das erste startete per Shell-Funktion eine vom Anwender im Dialog festgelegte Anwendung. Das zweite Makro legte eine Sicherungskopie des aktuellen Dokuments an, wozu es neben diversen Dateisystemfunktionen wie Dir oder MkDir auch den aus WordBasic übernommenen CopyFile-Befehl einsetzte. Makro drei übersetzte Zahlen in Zahlworte und verwendete dabei Standarddialoge für die Eingabe (InputBox) und Anzeige (MsgBox) von Texten. Makro vier ermöglichte das Abspielen einer Audio-CD, wozu es auf eine Funktion des Windows-API zurückgriff. Das fünfte Makro schließlich erstellte per COM-Automation ein Excel-Diagramm und fügte es in das Word-Dokument ein.

Beim dritten Testdokument (xlProgMakros.xls) handelte es sich um eine Excel-2003-Arbeitsmappe. Die enthielt nur programmierte Makros mit steigendem Schwierigkeitsgrad. Makro eins legte eine neue Tabelle an, fügte dieser zwei Zahlen hinzu und addierte deren Werte mit der Arbeitsblattfunktion SUMME(). Das zweite Makro generierte ein 3D-Kreisdiagramm auf der Grundlage einer neu angelegten Tabelle, die die Verkaufszahlen von drei Produkten enthielt. Das Besondere an dem Makro war die Verwendung von benannten Argumenten beim Aufruf der VBA-Anweisungen. Bei Makro Nummer drei kam ein selbsterstelltes (Userform-)Dialogfeld zum Einsatz, mit dessen Hilfe der Makro-Nutzer den Namen eines Arbeitsblatts auswählen konnte. Das vierte Makro schließlich verwendete ein Auto_Open-Makro, das beim Öffnen der Arbeitsmappe automatisch einen Befehl in die Menüleiste von Excel einfügte und diesen mit einem Makro verknüpfte. Beim Aufruf des Befehls öffnete das Makro ein weiteres Userform-Dialogfeld, mit dem der Anwender einen Monatskalender in das aktuelle Arbeitsblatt einfügen konnte.

Alles versucht

Nach Empfehlung von Sun sollte dem Einsatz des Macro Migration Wizard eine Analyse der Office-Dokumente mit Hilfe des mitgelieferten Professional Analysis Wizard vorausgehen. Das Tool fahndet nach möglichen Umstellungsproblemen nicht nur makrotechnischer, sondern auch inhaltlicher Art und dokumentiert diese in einer Excel-Tabelle. Den Testdokumenten bescheinigte es mittlere bis komplexe Probleme bei der Makrokonvertierung.

Unterm Strich wurde der Aufwand für eine manuelle Umstellung der insgesamt 14 Makros auf 5,7 Manntage (Arbeitstage pro Arbeitskraft) geschätzt. Der Restaufwand nach einer automatischen Umstellung sollte bei nur noch 3,4 Manntagen liegen, was einer rund 40-prozentigen Einsparung entspricht. Nach der Analyse bereitete der Wizard nach eigener Aussage alle drei Testdokumente für die Umstellung vor. Im Ausgabeordner fanden sich jedoch nur frisch gespeicherte Kopien der beiden Word-Dokumente, deren Inhalte und Makrocode aber keinerlei Veränderungen gegenüber den Originalen aufwiesen. Eine präparierte Version der Excel-Datei fehlte völlig, so dass wir die Arbeitsmappe von Hand in den Ausgabeordner kopieren mussten.

Die Ausgrenzung der XLS-Datei setzte sich beim Macro Migration Wizard fort. Das komfortable Tool konvertierte zwar die DOC-Files aus dem Ausgabeordner in ODT-Dateien, überging das Excel-Dokument komplett und ohne Warnung. Es fand sich zwar eine Protokolldatei, die allerdings leer war. Nach längerem Knobeln fand sich dann die schlichte Ursache der Verweigerungshaltung: es waren die Umlaute im Makronamen "Blätterwald", die beide Wizards aus dem Konzept gebracht hatten. Nach dem Umbenennen lief die Konvertierung problemlos.

Beim Öffnen der konvertierten Textdokumente mit StarOffice Writer zeigte sich, wie die Makroumwandlung grundsätzlich funktioniert. Und zwar nicht durch eine komplette Übersetzung des VBA-Codes in echten UNO-Code, wie sie ein Programmierer leisten würde. Stattdessen verwendet Sun die Laufzeitbibliothek MS Office Macro Runtime Library, die das Objektmodell von Microsoft nachbildet und somit möglichst identische Objektbezeichner und Parameterstrukturen verwendet. Das hat den Vorteil, dass der originale Makro-Code nur relativ wenig verändert werden muss, um in StarOffice zu funktionieren - zumindest in der Theorie.

In der Praxis erwies sich jedoch, dass die Entwicklung der Kompatibilitäts-Bibliothek noch lange nicht abgeschlossen ist. So stoppte die Ausführung von vier der fünf Makros in wdRecMakros.odt abrupt mit einer Fehlermeldung. Das Makro zum Ersetzen von Text lief zwar durch, ersetzte aber statt der geforderten ganzen Wörter jedes Vorkommen des Suchbegriffs, was wir dennoch als Erfolg gewertet haben. Bei den programmierten Makros sah es kaum besser aus. Hier konnte das Makro zum Starten von Anwendungen zwar den gewünschten Auswahldialog anzeigen, scheiterte jedoch an dem ihm unbekannten Shell-Befehl. Bei dem Sicherungsmakro wurde erwartungsgemäß der CopyFile-Befehl moniert. Das CD-Player-Makro verweigerte den Aufruf der API-Funktion und kannte darüber hinaus die BASIC-Funktion Chr$() nicht. Das Diagramm-Makro vermochte immerhin eine Instanz von Excel zu starten, brandmarkte dann allerdings die ChartType-Anweisung zur Festlegung der Diagrammart als fehlerhaft. Nur das Zahlwortmakro lief wie gewünscht.