Has anyone else found writing OpenOffice.org macros an exercise in hair-tearing frustration?
It gives you a choice of four different languages to write them in, which would be great if it didn’t make the documentation four times as long and complicated, and if at least one of them actually worked reliably and was easy to use.
The “documentation”, api.openoffice.org, is a maze of twisty little classes, all equally useless. How do I get, munge and then replace the current selection? It’s hardly an edge use case. Why do I need to work out if my XComponent can be UNO.QueryInterfaced to an XDocument, which doesn’t have a getCurrentSelection method anyway? XModel does, but it doesn’t have a setCurrentSelection() method, and all I could find about that little anomaly was a sarky mailing list message saying that the getCurrentSelection() method on XModel was a misfeature and I should use XComponent. “That’s what it’s there for.” Well, gee, thanks. Except that it doesn’t have any methods relating to the selection at all.
Searching doesn’t work. Each page has about three search boxes, two of which are the wrong one but you don’t know which two. Some take you off into the wilds of other websites and wikis which contain content which seems tantalisingly related to what you are doing but in fact is (as far as I can now tell) about OpenOffice.org’s C++ internal interfaces.
The “Macro Management” screen is an exercise in how not to design a UI to “manage” anything, with an utterly unnecessary and imposed three-level hierarchy of “Modules” and so on, where clicking the wrong button dismisses the dialog and makes you painfully reopen it from its home nested four levels deep in the menus and renavigate using a widget the size of a postage stamp back to the relevant place in the complex tree to try hitting the other button to see if it works any better.
What were they thinking? I bet VB is far easier than this.