Where do I start with API programming in LO?

Years ago, I wrote a VB app that opens an MS Word doc, and does ‘stuff’.
Now, I would like to migrate that program to use LibreOffice (4.3.1) instead of MS Word.
I’ve spent some time looking around, but perhaps I’m not using the correct terminology?

The ‘stuff’ I do is fairly simple using the DOM model in MS Word

  1. find the first table on the first page, get the row/col count and read the data.
  2. find all subsequent occurrences of that table (same rows/cols) throughout the document, read the data.

I’d like to interact with the Word doc using C++ or PHP (Using Windows 7).
I’m actually wondering if LibreOffice’s API (if there is one) is actually the way to go with this? Is there a better way?

Any pointers where to start would be very much appreciated…
Many thanks in advance…

I recommend starting with the links collected in this alternate forum thread. The guide by Andrew Pitonyak is generally cited as the best. You are probably going to have to use C++ in preference to PHP.

Thank-you :slight_smile:

Pitonyak’s guide refers specifically to macros. Is that what I’d need to use?

I need to write an automated tool, not one that requires manual intervention.

In this case you should ask on stackoverflow not here, try odfpy

or unzip your .odt and grep the relevant parts from content.xml

@dev_al, the term “macro” is used generally to mean program module (usually written in LO Basic, but also in other languages for which the UNO / API is available), rather than the more usual definition of a macroinstruction that is expanded / mapped.

I’m surprised we are being referred to other forums like http://en.libreofficeforum.org/node/6017. Many people like me used VBA with Microsoft Office without too much trouble despite its faults. There are (or were; I havn’t been there for a while) all sorts of user guides and code snippets on the web. Not all the snippets work, of course.

I can’t find a suitable beginners’ guide to the LO Basic equivalent, which is inevitably more difficult to use because autocompletion can’t be provided for structural reasons. There are third-part aids like X-ray Tools, but they may not be suitable for all newcomers to LO Basic.

One cause for confusion is that the LO 3 Basic guide seems to imply that you have to create a UNO service do do anything (code example: Obj = createUnoService(“com.sun.star.frame.Desktop”)).

On the other hand a recent example on the present forum (How to write macro programming?) doesn’t require such code, and starts like this after the Dim statements:

oSDescriptor => ThisComponent.createSearchDescriptor()



oSearchResult = ThisComponent.findAll(oSDescriptor)

Presumable the UNO service is already running in LO, but I’ll need to go on a “fishing expedition” to find some properties, services and syntax of “createSearchDescriptor()”.

At least question 25137 above shows that if you ask nicely, someone nice may do the coding for you :slight_smile:

In anwer to einpoklum (27 September) I have been searching for a while but didn’t find an answer. So I thought it would be fair to make and justify a comment to the effect that there isn’t an up-to-date ‘getting started’ guide suitable for end users, and that some kind of authoritative look-up facility is needed to compensate for the absence of auto-completion. Andrew Pitonyak’s “Macros Explained” document is excellent, but it’s written at a level suitable for developers. Perhaps LO developers havn’t realised how many “ordinary” MS Office users write macros that are a little beyond the reach of a macro recorder; comparable ease of use should be a “must have” for LO.

@oweng Your comment reinforces what I said in my reply above to einpoklum.

As clearly implied by the OP, for the last couple of decades “ordinary” users of Office software expect to have access to macro coding facilities, for which they can learn enough from books line “VBA for idiots”, and from the built-in help and the enormous amount of information that has become available over the years on the web. The same notion applies to hundreds of scientific, technical, educational and artistic applications, with the apparently unique exception of OO/LO. Writing code is a necessity for very many people, and no longer reserved for specialists: just look at any technical drawing, electronics design, maths or statistics package to see how it’s provided for. With some applications, such as the widely-used open-source maths package Scilab, all user input is in the form of code.

The feature of LO that distinguishes it from all that software is that with the available documentation it’s just too difficult to move on from “hello world” to performing simple manipulations on objects belonging to a LO document. It appears that the LO development team thinks it should stay like that; only IT professionals should be allowed to write code.

Despite one of oweng’s remarks, though I’m not an IT specialist I don’t count myself as a beginner here. Like most other scientists I started writing scientific “stuff” at the start of my career (in about 1971). On and off I’ve have had to write short applications as part of my job, for various computers and instruments with embedded software. Now well into retirement, my latest effort in C++ (which has to do with music) is probably more elaborate than many end-users’ Office macros. Like lots of people in all walks of life including schoolkids, I didn’t find writing Excel or Word macros (2003) much of a challenge - except when an object or method didn’t work as advertised. What prompted my reply here was the unpleasant surprise I exerienced when trying to automate some ‘tidying-up’ of a book a friend wrote in Word, so it could be exported from Writer to the eBook format ePub.

Sorry for the long discussion, but some “historical” background is needed to show that the LO team appears to have taken an unfortunate direction on an important point.

Most of what you wrote here seems to be commentary rather than the actual answer…

@crlMIDI, the Pitonyak guide (and likely every other guide) is “written at a level suitable for developers” because that is what an API is … advanced-level exposure of / access to the inner workings of a product i.e., programming. There is a significant difference between not knowing how to program and wanting to learn LO Basic vs having some knowledge of programming and wanting to learn. Those in the former group, should first learn some entry-level programming techniques.