Documentation/DevGuide/First Steps

This chapter shows you the first steps when using the LibreOffice API. Following these steps is essential to understand and use the chapters about LibreOffice documents such as Text Documents, Spreadsheet Documents, Drawing Documents and Presentation Documents. After you have successfully done the first steps, you can go directly to the other chapters of this manual.

The focus of the first steps will be Java, but other languages are covered as well. If you want to use LibreOffice Basic afterwards, please refer to the chapters First Steps with LibreOffice Basic and UNO Language Bindings. The usage of C++ is described in C++ Language Binding.

Programming With UNO
UNO (pronounced [ˈjuːnou]) stands for Universal Network Objects and is the base component technology for LibreOffice. You can utilize and write components that interact across languages, component technologies, computer platforms, and networks. Currently, UNO is available on Linux, Solaris, Windows, FreeBSD and macOS and other platforms that LibreOffice supports. The supported programming languages are C++, Java and LibreOffice Basic. In addition, UNO is available through the component technology Microsoft COM for many other languages. On LibreOffice there is also a language binding for Python available.

UNO is also programmable with .NET languages using the Common Language Infrastructure binding, but support for the latest cross platform .NET (formerly .NET Core) is not available yet. In addition, the new scripting framework offers the use of the API through several scripting languages, such as JavaScript, Beanshell or Python. See Scripting Framework for more details.

UNO is used to access LibreOffice, using its Application Programming Interface (API). The LibreOffice API is the comprehensive specification that describes the programmable features of LibreOffice.

Fields of Application for UNO
You can connect to a local or remote instance of LibreOffice from C++, Java and COM/DCOM. C++ and Java Desktop applications, Java servlets, Java Server Pages, JScript and VBScript, and languages, such as Delphi, Visual Basic and many others can use LibreOffice to work with Office documents.

It is possible to develop UNO Components in C++ or Java that can be instantiated by the office process and add new capabilities to LibreOffice. For example, you can write Chart Add-ins or Calc Add-ins, Add-ons, linguistic extensions, new file filters, database drivers. You can even write complete applications, such as a groupware client.

UNO components, as JavaBeans, integrate with Java IDEs (Integrated Development Environment) to give easy access to LibreOffice. Using OfficeBean, editing LibreOffice documents in Java Frames is possible. With this component, LibreOffice’s API is completely exposed so that all office components can be fully controlled.

LibreOffice Basic cooperates with UNO, so that UNO programs can be directly written in LibreOffice. With this method, you supply your own office solutions and wizards based on an event-driven dialog environment.

The LibreOffice database engine and the data aware forms open another wide area of opportunities for database driven solutions.

It should be noted that there is a new API for LibreOffice called LibreOfficeKit which can be used for accessing LibreOffice functionality through C/C++, without any need to use UNO. LibreOfficeKit uses tiled rendering, and it is used in LibreOffice Online and LibreOffice for Android.

Getting Started
A number of files and installation sets are required before beginning with the LibreOffice API.

Required Files
These files are required for any of the languages you use.

LibreOffice Installation
Install a copy of LibreOffice.

You can download LibreOffice from libreoffice.org/download.

Note: This book focuses on the current version.

API Reference
The LibreOffice API reference is part of the Software Development Kit and provides detailed information about LibreOffice objects. The latest version can always be found online on api.libreoffice.org/.

Installation Sets
The following installation sets are useful to develop LibreOffice API applications with Java.

JDK
Java applications for LibreOffice require the Java Development Kit 9 or later. Download and install a JDK from adoptopenjdk.net,oracle.com (Oracle requires login to download), or microsoft.com (Microsoft does not require login).

You should install a 32-bit JDK if you are using 32-bit OS, and a 64-bit JDK if you are using 64-bit OS. The recommendation is to always use the latest official Java version because of important bug fixes. JDK versions prior to 11 are not supported anymore (although companies other than Oracle provide some support), thus it is suggested to use at least version 11 of the JDK.

LibreOffice Software Development Kit (SDK)
Obtain the LibreOffice Software Development Kit (SDK) from libreoffice.org/download. It contains the build environment for the examples mentioned in this manual and reference documentation for the LibreOffice API, for the Java UNO runtime, and the C++ API. It also offers more example sources. By means of the SDK you can use GNU  to build and run the examples we mention here.

Install the SDK on your system. The index.html file inside the SDK folder gives an overview of the SDK. For detailed instructions which compilers to use and how to set up your development environment, please refer to the SDK installation guide.

Enable Java in LibreOffice
LibreOffice uses a Java Virtual Machine to instantiate components written in Java. From OpenOffice.org 2.x on, Java is found automatically during startup, or latest when Java functionality is required. If you prefer to preselect a JRE or JDK, or if no Java is found, you can configure Java using the dialog in LibreOffice and select the section. In older versions of LibreOffice you can also easily tell the office which JVM to use: launch the  executable from the programs folder under the LibreOffice, select an installed JRE or JDK and click OK. Close the LibreOffice in the taskbar and restart LibreOffice. Furthermore, open the dialog in LibreOffice, select the section  and make sure that the Java enable option is checked.

Getting Started
It is relatively simple to get a working environment that offers a transparent use of UNO functionality and of office functionality. The following demonstrates how to write and build a small program that initializes UNO, which means that it internally connects to an office or starts a new office process if necessary and tells you if it was able to get the office component context that provides the office service manager object.

The FirstUnoContact example
The FirstUnoContact example that connects to the office:

For editing and running the example in Java, start a Java IDE or source editor, and enter the source code for the FirstUnoContact  class inside the   folder. In order to automate the build process, you can set up sdk environment in, and then use   inside   folder, and then.

To compile the C++ example, you should refer to the LibreOffice SDK.

To run the Python example, you should use the Python bundled with LibreOffice:

If the example runs successfully, you should see this output, after the debug output from the program:

Otherwise, you may see the output that says:.

For an example that connects to the office with C++, see chapter C++ Language Binding. Accessing the office with LibreOffice Basic is described in First Steps with LibreOffice Basic.

The next section describes what happens during the connection between a Java program and LibreOffice.

Service Managers
UNO introduces the concept of service managers, which can be considered as “factories” that create services. For now, it is sufficient to see services as UNO objects that can be used to perform specific tasks. Later on we will give a more precise definition for the term service. For example, the following services are available:

 com.sun.star.frame.Desktop 
 * maintains loaded documents: is used to load documents, to get the current document, and access all loaded documents

 com.sun.star.configuration.ConfigurationProvider 
 * yields access to the LibreOffice configuration, for instance the settings in the Tools > Options dialog

 com.sun.star.sdb.DatabaseContext 
 * holds databases registered with LibreOffice

 com.sun.star.system.SystemShellExecute 
 * executes system commands or documents registered for an application on the current platform

 com.sun.star.text.GlobalSettings 
 * manages global view and print settings for text documents



A service always has a component context, which consists of the service manager that created the service and other data to be used by the service.

The FirstUnoContact class above is considered a client of the LibreOffice process, LibreOffice is the server in this respect. The server has its own component context and its own service manager, which can be accessed from client programs to use the office functionality. The client program initializes UNO and gets the component context from the LibreOffice process. Internally, this initialization process creates a local service manager, establishes a pipe connection to a running LibreOffice process (if necessary a new process is started) and returns the remote component context. In the first step this is the only thing you have to know. The com.sun.star.comp.helper.Bootstrap.bootstrap method initializes UNO and returns the remote component context of a running LibreOffice process. You can find more details about bootstrapping UNO, the opportunities of different connection types and how to establish a connection to a UNO server process in the UNO Concepts.

After this first initialization step, you can use the method com.sun.star.uno.XComponentContext:getServiceManager from the component context to get the remote service manager from the LibreOffice process, which offers you access to the complete office functionality available through the API.

Failed Connections
A remote connection can fail under certain conditions:


 * Client programs should be able to detect errors. For instance, sometimes the bridge might become unavailable. Simple clients that connect to the office, perform a certain task and exit afterwards should stop their work and inform the user if an error occurred.
 * Clients that are supposed to run over a long period of time should not assume that a reference to an initial object will be valid over the whole runtime of the client. The client should resume even if the connection goes down for some reason and comes back later on. When the connection fails, a robust, long running client should stop the current work, inform the user that the connection is not available and release the references to the remote process. When the user tries to repeat the last action, the client should try to rebuild the connection. Do not force the user to restart your program just because the connection was temporarily unavailable.

When the bridge has become unavailable and access is tried, it throws a com.sun.star.lang.DisposedException. Whenever you access remote references in your program, catch this Exception in such a way that you set your remote references to null and inform the user accordingly. If your client is designed to run for a longer period of time, be prepared to get new remote references when you find that they are currently null.

A more sophisticated way to handle lost connections is to register a listener at the underlying bridge object. The chapter UNO Interprocess Connections shows how to write a connection-aware client.

How to get Objects in LibreOffice
An object in our context is a software artifact that has methods you can call. Objects are required to do something with LibreOffice. But where do you obtain them?

New objects
In general, new objects or objects which are necessary for a first access are created by service managers in LibreOffice. In the  example, the remote service manager creates the remote   object, which handles application windows and loaded documents in LibreOffice:

Document objects
Document objects represent the files that are opened with LibreOffice. They are created by the  object, which has a   method for this purpose.

Objects that are provided by other objects
Objects can hand out other objects. There are two cases:


 * Integral parts: Features which are designed to be an integral part of the object that provides the feature can be obtained by get methods in the LibreOffice API. It is common to get an object from a get method. For instance,  is required for every Calc document,   is essential for every Writer Document and   is an essential part of every Draw document. After loading a document, these methods are used to get the Sheets, Text and Drawpages object of the corresponding document. Object-specific get methods are an important technique to get objects.


 * Non-integral parts: Features which are not considered integral for the architecture of an object are accessible through a set of universal methods. In the LibreOffice API, these features are called properties, and generic methods are used, such as  to access them. In some cases such a non-integral feature is provided as an object, therefore the method   can be another source for objects. For instance, page styles for spreadsheets have the properties   and , that contain objects for the page header sections of a spreadsheet document. The generic   method can sometimes provide an object you need.

Sets of objects
Objects can be elements in a set of similar objects. In sets, to access an object you need to know how to get a particular element from the set. The LibreOffice API allows four ways to provide an element in a set. The first three ways are objects with element access methods that allow access by name, index, or enumeration. The fourth way is a sequence of elements which has no access methods but can be used as an array directly. How these sets of elements are used will be discussed later.

The designer of an object decides which of those opportunities to offer, based on special conditions of the object, such as how it performs remotely or which access methods best work with implementation.

Working with Objects
Working with LibreOffice API objects involves the following:


 * First we will learn the UNO concepts of objects, interfaces, services, attributes, and properties, and we will get acquainted with UNO's method of using them.
 * After that, we will work with a LibreOffice document for the first time, and give some hints for the usage of the most common types in LibreOffice API.
 * Finally we will introduce the common interfaces that allow you to work with text, tables and drawings across all LibreOffice document types.

Objects
In UNO, an object is a software artifact that has methods that you can call and attributes that you can get and set. Exactly which methods and attributes an object offers is specified by the set of interfaces it supports.

Interfaces
An interface specifies a set of attributes and methods that together define one single aspect of an object. For instance, the interface com.sun.star.resource.XResourceBundle specifies the attribute  and the methods   and.

To allow for reuse of such interface specifications, an interface can inherit one or more other interfaces (as, for example, com.sun.star.resource.XResourceBundle inherits all the attributes and methods of com.sun.star.container.XNameAccess ). Multiple inheritance, the ability to inherit more than one interface, was introduced in OpenOffice.org 2.x.

Strictly speaking, interface attributes are not needed in UNO. Each attribute could also be expressed as a combination of one method to get the attribute's value, and another method to set it (or just one method to get the value for a read-only attribute). However, there are at least two good reasons for the inclusion of interface attributes in UNO: First, the need for such combinations of getting and setting a value seems to be widespread enough to warrant extra support. Second, with attributes, a designer of an interface can better express nuances among the different features of an object. Attributes can be used for those features that are not considered integral or structural parts of an object, while explicit methods are reserved to access the core features.

Historically, a UNO object typically supported a set of many independent interfaces, corresponding to its many different aspects. With multiple-inheritance interfaces, there is less need for this, as an object may now support just one interface that inherits from all the other interfaces that make up the object’s various aspects.

Services
Historically, the term “service” has been used with an unclear meaning in UNO. Starting with OpenOffice.org 2.x, the underlying concepts have been made cleaner. Unfortunately, this leaves two different meanings for the term “service” within UNO. In the following, we will use the term "new-style service" to denote an entity that conforms to the clarified, OpenOffice.org-OpenOffice.org 2.x service concept, while we use "old-style service" to denote an entity that only conforms to the historical, more vague concept. To make matters even more complicated, the term “service” is often used with still different meanings in contexts outside UNO.

Although technically there should no longer be any need for old-style services, the LibreOffice API still uses them extensively to remain backwards compatible. Therefore, be prepared to encounter uses of both service concepts in parallel when working with the LibreOffice API.

A new-style service is of the form

and specifies that objects that support a certain interface (for example, com.sun.star.bridge.XUnoUrlResolver ) will be available under a certain service name (e.g., "com.sun.star.bridge.UnoUrlResolver") at a component context’s service manager. (Formally, new-style services are called “single-interface–based services.”)

The various UNO language bindings offer special constructs to easily obtain instances of such new-style services, given a suitable component context; see Java Language Binding and C++ Language Binding.

An old-style service (formally called an “accumulation-based service”) is of the form

and is used to specify any of the following:


 * The general contract is that, if an object is documented to support a certain old-style service, then you can expect that object to support all interfaces exported by the service itself and any inherited services. For example, the method com.sun.star.frame.XFrames:queryFrames returns a sequence of objects that should all support the old-style service com.sun.star.frame.Frame, and thus all the interfaces exported by com.sun.star.frame.Frame.
 * Additionally, an old-style service may specify one or more properties, as in


 * Properties, which are explained in detail in the following section, are similar to interface attributes, in that they describe additional features of an object. The main difference is that interface attributes can be accessed directly, while the properties of an old-style service are typically accessed via generic interfaces like com.sun.star.beans.XPropertySet . Often, interface attributes are used to represent integral features of an object, while properties represent additional, more volatile features.


 * Some old-style services are intended to be available at a component context’s service manager. For example, the service com.sun.star.frame.Desktop can be instantiated at a component context’s service manager under its service name "com.sun.star.frame.Desktop". (The problem is that you cannot tell whether a given old-style service is intended to be available at a component context; using a new-style service instead makes that intent explicit.)


 * Other old-style services are designed as generic super-services that are inherited by other services. For example, the service com.sun.star.document.OfficeDocument serves as a generic base for all different sorts of concrete document services, like com.sun.star.text.TextDocument and com.sun.star.drawing.DrawingDocument . (Multiple-inheritance interfaces are now the preferred mechanism to express such generic base services.)


 * Yet other old-style services only list properties, and do not export any interfaces at all. Instead of specifying the interfaces supported by certain objects, as the other kinds of old-style services do, such services are used to document a set of related properties. For example, the service com.sun.star.document.MediaDescriptor lists all the properties that can be passed to com.sun.star.frame.XComponentLoader:loadComponentFromURL.

A property is a feature of an object which is typically not considered an integral or structural part of the object and therefore is handled through generic /  methods instead of specialized get methods, such as. Old-style services offer a special syntax to list all the properties of an object. An object containing properties only has to support the com.sun.star.beans.XPropertySet interface to be prepared to handle all kinds of properties. Typical examples are properties for character or paragraph formatting. With properties, you can set multiple features of an object through a single call to, which greatly improves the remote performance. For instance, paragraphs support the  method through their com.sun.star.beans.XMultiPropertySet interface.

Using Services
The concepts of interfaces and services were introduced for the following reasons:

Interfaces and services separate specification from implementation
 * The specification of an interface or service is abstract, that is, it does not define how objects supporting a certain functionality do this internally. Through the abstract specification of the LibreOffice API, it is possible to pull the implementation out from under the API and install a different implementation if required.

Service names allow to create instances by specification name, not by class names
 * In Java or C++ you use the new operator to create a class instance. This approach is restricted: the class you get is hard-coded. You cannot later on exchange it by another class without editing the code. The concept of services solves this. The central object factory in LibreOffice, the global service manager, is asked to create an object that can be used for a certain purpose without defining its internal implementation. This is possible because a service can be ordered from the factory by its service name and the factory decides which service implementation it returns. Which implementation you get makes no difference, you only use the well-defined interface of the service.

Interfaces
Abstract interfaces are more reusable if they are fine-grained, i.e., if they are small and describe only a single aspect of an object. To describe the many aspects of an object, objects can implement more than one of these fine-grained interfaces. Being able to implement multiple interfaces allows similar aspects of similar objects to be accessed with the same code. For example, many objects support text: text may be found in the body of a document, in text frames, in headers and footers, footnotes, table cells, and in drawing shapes. These objects all support the same interface, so a procedure can use, for example, getText to retrieve text from any of these objects.

Services, interfaces, and methods are illustrated in the figure below for the old-style service com.sun.star.text.TextDocument, shown using UML notation. In this figure, services are shown on the left side. The arrow between services indicates that one service provided by the upper (arrowhead) service are inherited by the lower service. Interfaces exported by these services are shown on the right. All interface names in the LibreOffice API start with an X, so as to be distinguishable from the names of other entities. Each interface contains methods, which are listed beneath the interface.



A  object provides the com.sun.star.text.TextDocument service, which implements the interfaces, ,  , and. These interfaces provide, for example, the methods, for adding text to a document, and  , for searching the document.

As indicated by the arrow, the com.sun.star.text.TextDocument service also inherits all the interfaces provided by the com.sun.star.document.OfficeDocument service, so these interfaces are also provided to a  object. These interfaces handle tasks common to the LibreOffice applications: printing,  ; storing,  ; modifying,  ; and model handling,.

The interfaces shown in the figure are only the mandatory interfaces of a  object. A  has optional properties and interfaces, among them the properties ,   and  , and the interface   , which must be supported if properties are present at all. The implementation of the  service in LibreOffice supports both required and all optional interfaces as well. The usage of a  is described thoroughly in Text Documents.

C++ and Java require that the interface name be provided when accessing a method. An old-style service may provide several interfaces to keep track of. New-style services are easier to use because, since they have just one interface, the multiple-inheritance interface, all the methods are accessed through the same interface.

Using Interfaces
The fact that every UNO object must be accessed through its interfaces has an effect in languages like Java and C++, where the compiler needs the correct type of an object reference before you can call a method from it. In Java or C++, you normally just cast an object before you access an interface it implements. When working with UNO objects this is different: You must ask the UNO environment to get the appropriate reference for you whenever you want to access methods of an interface which your object supports, but your compiler does not yet know about. Only then you can cast it safely.

The Java UNO environment has a method  for this purpose. It looks complicated at first sight, but once you understand that  is about safe casting of UNO types across process boundaries, you will soon get used to it. Take a look at the second example FirstLoadComponent.java (in the sample directory, if you have installed the SDK on your computer), where a new Desktop object is created and, afterwards, the com.sun.star.uno.XInterface:queryInterface method is used to get the com.sun.star.frame.XComponentLoader interface.

We asked the service manager to create a com.sun.star.frame.Desktop using its factory method createInstanceWithContext. This method is defined to return a Java Object type, which should not surprise you—after all the factory must be able to return any type:

The object we receive is a com.sun.star.frame.Desktop service. The point is, while we know that the object we ordered at the factory is a DesktopUnoUrlResolver and exports among other interfaces the interface, the compiler does not. Therefore, we have to use the UNO runtime environment to ask or query for the interface, since we want to use the   method on this interface. The method  makes sure we get a reference that can be cast to the needed interface type, no matter if the target object is a local or a remote object. There are two  definitions in the Java UNO language binding:

Since  is specified to return a java.lang.Object just like the factory method , we still must explicitly cast our interface reference to the needed type. The difference is that after  we can safely cast the object to our interface type and, most important, that the reference will now work even with an object in another process. Here is the  call, explained step by step:

is the interface we want to use, so we define a  variable named   (lower x) to store the interface we expect from. Then we query our desktop object for the  interface, passing in   as target interface and desktop as source object. Finally we cast the outcome to  and assign the resulting reference to our variable. If the source object does not support the interface we are querying for,  will return null.

In Java, this call to  is necessary whenever you have a reference to an object which is known to support an interface that you need, but you do not have the proper reference type yet. Fortunately, you are not only allowed to  from   source types, but you may also query an interface from another interface reference, like this:

Furthermore, if a method is defined in such a way that it already returns an interface type, you do not need to query the interface, but you can use its methods right away. In the snippet above, the method  is specified to return an com.sun.star.lang.XComponent interface, so you may call the   methods   and   directly at the   variable, if you want to be notified that the document is being closed.

The corresponding step in C++ is done by a  template that takes the source instance as parameter:

In LibreOffice Basic, querying for interfaces is not necessary; the Basic runtime engine takes care of that internally.

With the proliferation of multiple-inheritance interfaces in the LibreOffice API, there will be less of a demand to explicitly query for specific interfaces in Java or C++. For example, with the hypothetical interfaces

you can directly call both  and   on a reference obtained through , without querying for either   or.

Using Properties
An object must offer its properties through interfaces that allow you to work with properties. The most basic form of these interfaces is the interface com.sun.star.beans.XPropertySet. There are other interfaces for properties, such as com.sun.star.beans.XMultiPropertySet, that gets and sets a multitude of properties with a single method call. The  is always supported when properties are present in a service.

In, two methods carry out the property access, which are defined in Java as follows:

In the FirstLoadComponent example, the  interface was used to set the CellStyle property at a cell object. The cell object was a  and therefore supports also the   service which had a property. The following code explains how this property was set:

You are now ready to start working with an LibreOffice document.

Example: Working with a Spreadsheet Document
In this example, we will use the simple bootstrap mechanism (com.sun.star.comp.helper.Bootstrap.Bootstrap) to get the remote office context of a running office instance and ask the remote service manager to give us the remote  object and use its   method to create a new spreadsheet document. From the document we get its sheets container where we insert and access a new sheet by name. In the new sheet, we enter values into A1 and A2 and summarize them in A3. The cell style of the summarizing cell gets the cell style Result, so that it appears in italics, bold and underlined. Finally, we make our new sheet the active sheet, so that the user can see it.

The FirstLoadComponent class
This is the FirstLoadComponent example, available inside the  folder. Again, you should set up sdk environment in, and then use   inside   folder, and then.

Common Types
Until now, literals and common Java types for method parameters and return values have been used as if the LibreOffice API was made for Java. However, it is important to understand that UNO is designed to be language independent and therefore has its own set of types which have to be mapped to the proper types for your language binding. The type mappings are briefly described in this section. Refer to Documentation/DevGuide/Professional_UNO for detailed information about type mappings.

Basic Types
The basic UNO types (where the term “basic” has nothing to do with LibreOffice Basic) occur as members of structs, as method return types or method parameters. The following table shows the basic UNO types and, if available, their exact mappings to Java, C++, and LibreOffice Basic types.

There are special conditions for types that do not have an exact mapping in this table. Check for details about these types in the corresponding sections about type mappings in UNO Language Bindings.

Strings
UNO considers strings to be simple types, but since they need special treatment in some environments, we discuss them separately here.

In Java, use UNO strings as if they were native  objects. In C++, native  strings must be converted to UNO Unicode strings by means of SAL conversion functions, usually the function   in the   class:

In Basic, Basic strings are mapped to UNO strings transparently.

Enum Types and Groups of Constants
The LibreOffice API uses many enumeration types (called enums) and groups of constants (called constant groups). Enums are used to list every plausible value in a certain context. The constant groups define possible values for properties, parameters, return values and struct members.

For example, there is an enum com.sun.star.table.CellVertJustify that describes the possible values for the vertical adjustment of table cell content. The vertical adjustment of table cells is determined by their property com.sun.star.table.CellProperties:VertJustify. The possible values for this property are, according to, the values  ,  ,   and.

LibreOffice Basic understands enumeration types and constant groups. Their usage is straightforward:

In C++ enums and constant groups are used with the scope operator

Struct
Structs in the LibreOffice API are used to create compounds of other UNO types. They correspond to C structs or Java classes consisting of public member variables only.

While structs do not encapsulate data, they are easier to transport as a whole, instead of marshaling  and   calls back and forth. In particular, this has advantages for remote communication.

You gain access to struct members through the. (dot) operator as in

In Java, C++ and LibreOffice Basic, the keyword  instantiates structs. In OLE automation, use com.sun.star.reflection.CoreReflection to get a UNO struct. Do not use the service manager to create structs.

Any
The LibreOffice API frequently uses an  type, which is the counterpart of the   type known from other environments. The  type holds one arbitrary UNO type. The  type is especially used in generic UNO interfaces.

Examples for the occurrence of any are the method parameters and return values of the following, frequently used methods:

The  type also occurs in the com.sun.star.beans.PropertyValue struct.



This  has two member variables,   and , and is ubiquitous in sets of   structs, where every   is a name-value pair that describes a property by name and value. If you need to set the value of such a, you must assign an   type, and you must be able to interpret the contained  , if you are reading from a. How this is done depends on your language.

In Java, the  type is mapped to , but there is also a special Java class  , mainly used in those cases where a plain   would be ambiguous. There are two simple rules of thumb to follow:


 * 1. When you are supposed to pass in an  value, always pass in a   or a Java UNO object.

For instance, if you use  to set a property that has a non-interface type in the target object, you must pass in a   for the new value. If the new value is of a primitive type in Java, use the corresponding  type for the primitive type:

Another example would be a  struct you want to use for  :


 * 2. When you receive an  instance, always use the   to retrieve its value.

The  requires a closer look. For instance, if you want to get a property which contains a primitive Java type, you must be aware that  returns a   containing your primitive type wrapped in an any value. The  is a converter for such objects. Actually it can do more than just conversion, you can find its specification in the Java UNO reference. The following list sums up the conversion functions in the :

Its usage is straightforward:

For convenience, for interface types you can directly use  without first calling  :

In LibreOffice Basic, the  type becomes a Variant:

In C++, there are special operators for the  type:

Sequence
A sequence is a homogeneous collection of values of one UNO type with a variable number of elements. Sequences map to arrays in most current language bindings. Although such collections are sometimes implemented as objects with element access methods in UNO (e.g., via the com.sun.star.container.XEnumeration interface), there is also the sequence type, to be used where remote performance matters. Sequences are always written with pointed brackets in the API reference:

In Java, you treat sequences as arrays. (But do not use  for empty sequences, use arrays created via   and with a length of zero instead.) Furthermore, keep in mind that you only create an array of references when creating an array of Java objects, the actual objects are not allocated. Therefore, you must use  to create the array itself, then you must again use   for every single object and assign the new objects to the array.

An empty sequence of  structs is frequently needed for  :

A sequence of  structs is needed to use loading parameters with. The possible parameter values for  and the com.sun.star.frame.XStorable interface can be found in the service com.sun.star.document.MediaDescriptor.

In LibreOffice Basic, a simple  creates an empty array.

A sequence of structs is created using new together with.

In C++, there is a class template for sequences. An empty sequence can be created by omitting the number of elements required.

If you pass a number of elements, you get an array of the requested length.

Element Access
We have already seen in the section How to get Objects in LibreOffice that sets of objects can also be provided through element access methods. The three most important kinds of element access interfaces are com.sun.star.container.XNameContainer, com.sun.star.container.XIndexContainer and com.sun.star.container.XEnumeration.

The three element access interfaces are examples of how the fine-grained interfaces of the LibreOffice API allow consistent object design.

All three interfaces inherit from ; therefore, they include the methods

for finding out basic information about a set of elements. The method  tells whether or not a set contains any elements at all; the method   tells which type a set contains. In Java and C++, you can get information about a UNO type through, cf, the Java UNO and the C++ UNO reference.

The com.sun.star.container.XIndexContainer and com.sun.star.container.XNameContainer interface have a parallel design. Consider both interfaces in UML notation.



The  interfaces are about getting an element. The  interfaces allow you to replace existing elements without changing the number of elements in the set, whereas the   interfaces allow you to increase and decrease the number of elements by inserting and removing elements.

Many sets of named or indexed objects do not support the whole inheritance hierarchy of  or , because the capabilities added by every subclass are not always logical for any set of elements.

The  interface works differently from named and indexed containers below the   interface. does not provide single elements like  and , but it creates an enumeration of objects which has methods to go to the next element as long as there are more elements.



Sets of objects sometimes support all element access methods, some also support only name, index, or enumeration access. Always look up the various types in the API reference to see which access methods are available.

For instance, the method  at the interface com.sun.star.sheet.XSpreadsheetDocument is specified to return a com.sun.star.sheet.XSpreadsheets interface inherited from. In addition, the API reference tells you that the provided object supports the com.sun.star.sheet.Spreadsheets service, which defines additional element access interfaces besides.

Examples that show how to work with,  , and   are provided below.

Name Access
The basic interface which hands out elements by name is the com.sun.star.container.XNameAccess interface. It has three methods:

In the FirstLoadComponent.java example above, the method  returned a com.sun.star.sheet.XSpreadsheets interface, which inherits from. Therefore, you could use  to obtain the sheet "MySheet" by name from the   container:

Since  returns an any, you have to use   and/or   before you can call methods at the spreadsheet object.

Index Access
The interface which hands out elements by index is the com.sun.star.container.XIndexAccess interface. It has two methods:

The FirstLoadComponent example allows to demonstrate. The API reference tells us that the service returned by  is a com.sun.star.sheet.Spreadsheet service and supports not only the interface com.sun.star.sheet.XSpreadsheets, but   as well. Therefore, the sheets could have been accessed by index and not just by name by performing a query for the  interface from our   variable:

Enumeration Access
The interface com.sun.star.container.XEnumerationAccess creates enumerations that allow traveling across a set of objects. It has one method:.

The enumeration object gained from  supports the interface com.sun.star.container.XEnumeration. With this interface we can keep pulling elements out of the enumeration as long as it has more elements. supplies the methods  and   which are meant to build loops such as:

For example, in spreadsheets you have the opportunity to find out which cells contain formulas. The resulting set of cells is provided as.

The interface that queries for cells with formulas is com.sun.star.sheet.XCellRangesQuery, it defines (among others) a method  which queries for cells having content as defined in the constants group com.sun.star.sheet.CellFlags. One of these cell flags is. From  we receive an object with an com.sun.star.sheet.XSheetCellRanges interface, which has these methods: ,   and.

The method  can be used to list all formula cells and the containing formulas in the spreadsheet document from our FirstLoadComponent example, utilizing.

How Do I Know Which Type I Have?
A common problem is deciding what capabilities an object really has, after you receive it from a method. By observing the code completion in Java IDE, you can discover the base interface of an object returned from a method. You will notice that loadComponentFromURL returns a com.sun.star.lang.XComponent.

By pressing in the NetBeans IDE you can read specifications about the interfaces and services you are using.

However, methods can only be specified to return one interface type. The interface you get from a method very often supports more interfaces than the one that is returned by the method (especially when the design of those interfaces predates the availability of multiple-inheritance interface types in UNO). Furthermore, the interface does not tell anything about the properties the object contains.

Therefore you should use this manual to get an idea how things work. Then start writing code, using the code completion and the API reference.

In addition, you can try the InstanceInspector, a Java tool which is part of the LibreOffice SDK examples. It is a Java component that can be registered with the office and shows interfaces and properties of the object you are currently working with.

In LibreOffice Basic, you can inspect objects using the following Basic properties.

For a complex object, these msgBox calls will run right off the screen. Try the following, instead:

This produces a new Writer document, containing the retrieved information.

Using these DBG properties is a very crude method to discover the contents of an API objects. Use instead Xray tool or MRI tool.

Example: Hello Text, Hello Table, Hello Shape
The goal of this section is to give a brief overview of those mechanisms in the LibreOffice API that are common to all document types. The three main application areas of LibreOffice are text, tables and drawing shapes. The point is: texts, tables and drawing shapes can occur in all three document types, no matter if you are dealing with a Writer, Calc or Draw/Impress file, but they are treated in the same manner everywhere. When you master the common mechanisms, you will be able to insert and use texts, tables and drawings in all document types.

Common Mechanisms for Text, Tables and Drawings
We want to stress the common ground, therefore we start with the common interfaces and properties that allow to manipulate existing texts, tables and drawings. Afterwards we will demonstrate the different techniques to create text, table and drawings in each document type.

The key interfaces and properties to work with existing texts, tables and drawings are the following:

For text the interface com.sun.star.text.XText contains the methods that change the actual text and other text contents (examples for text contents besides conventional text paragraphs are text tables, text fields, graphic objects and similar things, but such contents are not available in all contexts). When we talk about text here, we mean any text - text in text documents, text frames, page headers and footers, table cells or in drawing shapes. is the key for text everywhere in LibreOffice.



The interface com.sun.star.text.XText has the ability to set or get the text as a single string, and to locate the beginning and the end of a text. Furthermore,  can insert strings at an arbitrary position in the text and create text cursors to select and format text. Finally,  handles text contents through the methods   and , although not all texts accept text contents other than conventional text. In fact,  covers all this by inheriting from com.sun.star.text.XSimpleText that is inherited from com.sun.star.text.XTextRange.

Text formatting happens through the properties which are described in the services com.sun.star.style.ParagraphProperties and com.sun.star.style.CharacterProperties.

The following example method  adds text, then it uses a text cursor to select and format a few words using , afterwards it inserts more text. The method  only contains the most basic methods of   so that it works with every text object. In particular, it avoids, since there are no text contents except for conventional text that can be inserted in all text objects.

In tables and table cells, the interface com.sun.star.table.XCellRange allows you to retrieve single cells and subranges of cells. Once you have a cell, you can work with its formula or numeric value through the interface com.sun.star.table.XCell.



Table formatting is partially different in text tables and spreadsheet tables. Text tables use the properties specified in com.sun.star.text.TextTable, whereas spreadsheet tables use com.sun.star.table.CellProperties. Furthermore there are table cursors that allow to select and format cell ranges and the contained text. But since a com.sun.star.text.TextTableCursor works quite differently from a com.sun.star.sheet.SheetCellCursor, we will discuss them in the chapters about text and spreadsheet documents.

On drawing shapes, the interface com.sun.star.drawing.XShape is used to determine the position and size of a shape.



Everything else is a matter of property-based formatting and there is a multitude of properties to use. LibreOffice comes with eleven different shapes that are the basis for the drawing tools in the GUI (graphical user interface). Six of the shapes have individual properties that reflect their characteristics. The six shapes are:

Five shapes have no individual properties, rather they share the properties defined in the service com.sun.star.drawing.PolyPolygonBezierDescriptor :
 * com.sun.star.drawing.EllipseShape for circles and ellipses.
 * com.sun.star.drawing.RectangleShape for boxes.
 * com.sun.star.drawing.TextShape for text boxes.
 * com.sun.star.drawing.CaptionShape for labeling.
 * com.sun.star.drawing.MeasureShape for metering.
 * com.sun.star.drawing.ConnectorShape for lines that can be "glued" to other shapes to draw connecting lines between them.


 * com.sun.star.drawing.LineShape is for lines and arrows.
 * com.sun.star.drawing.PolyLineShape is for open shapes formed by straight lines.
 * com.sun.star.drawing.PolyPolygonShape is for shapes formed by one or more polygons.
 * com.sun.star.drawing.ClosedBezierShape is for closed bezier shapes.
 * com.sun.star.drawing.PolyPolygonBezierShape is for combinations of multiple polygon and Bezier shapes.

All of these eleven shapes use the properties from the following services:


 * com.sun.star.drawing.Shape describes basic properties of all shapes such as the layer a shape belongs to, protection from moving and sizing, style name, 3D transformation and name.
 * com.sun.star.drawing.LineProperties determines how the lines of a shape look.
 * com.sun.star.drawing.Text has no properties of its own, but includes:
 * com.sun.star.drawing.TextProperties that affects numbering, shape growth and text alignment in the cell, text animation and writing direction.
 * com.sun.star.style.ParagraphProperties is concerned with paragraph formatting.
 * com.sun.star.style.CharacterProperties formats characters.
 * com.sun.star.drawing.ShadowProperties deals with the shadow of a shape.
 * com.sun.star.drawing.RotationDescriptor sets rotation and shearing of a shape.
 * com.sun.star.drawing.FillProperties is only for closed shapes and describes how the shape is filled.
 * com.sun.star.presentation.Shape adds presentation effects to shapes in presentation documents.

Consider the following example showing how these properties work:

Creating Text, Tables and Drawing Shapes
The three  methods above took text, table and shape objects as parameters and altered them. The following methods show how to create such objects in the various document types. Note that all documents have their own service factory to create objects to be inserted into the document. Aside from that it depends very much on the document type how you proceed. This section only demonstrates the different procedures, the explanation can be found in the chapters about Text, Spreadsheet and Drawing Documents.

First, a small convenience method is used to create new documents.

Text, Tables and Drawings in Writer
The method  creates a writer document and manipulates its text, then uses the document's internal service manager to instantiate a text table and a shape, inserts them and manipulates the table and shape. Refer to Text Documents for more detailed information.

Text, Tables and Drawings in Calc
The method  creates a calc document, uses its document factory to create a shape and manipulates the cell text, table and shape. The chapter Spreadsheet Documents treats all aspects of spreadsheets.

Drawings and Text in Draw
The method  creates a draw document and uses its document factory to instantiate and add a shape, then it manipulates the shape. The chapter Drawing Documents and Presentation Documents casts more light on drawings and presentations.