Documentation/DevGuide/ Developers Guide

From Apache OpenOffice Wiki
< Documentation‎ | DevGuide
Revision as of 12:51, 20 June 2007 by Cc208500 (Talk)

Jump to: navigation, search


What This Manual Covers

This manual describes how to write programs using the component technology UNO (Universal Network Objects) with

Most examples provided are written in Java. As well as Java, the language binding for C++, the UNO access for Basic and the OLE Automation bridge that uses through Microsoft's component technology COM/DCOM is described.

How This Book is Organized

First Steps

The First Steps chapter describes the setting up of a Java UNO development environment to achieve the solutions you need. At the end of this chapter, you will be equipped with the essentials required for the following chapters about the applications.

Professional UNO Projects

This chapter introduces API and UNO concepts and explains the specifics of the programming languages and technologies that can be used with UNO. It will help you to write industrial strength UNO programs, use one of the languages besides Java or improve your understanding of the API reference.

Writing UNO Components

This chapter describes how to write UNO components. It also provides an insight into the UNOIDL (UNO Interface Definition Language) language and the inner workings of service manager. Before beginning this chapter, you should be familiar with the First Steps and Professional UNO chapters.

Advanced UNO

This chapter describes the technical basis of UNO, how the language bindings and bridges work, how the service manager goes about its tasks and what the core reflection actually does.

Office Development

This chapter describes the application framework of the application that includes how the API deals with the application and the features available across all parts of

Text Documents - Spreadsheet Documents - Drawings and Presentations – Chart

These chapters describes how revolves around documents. These chapters teach you what to do with these documents programmatically.

Basic and Dialogs

This chapter provides the functionality to create and manage Basic macros and dialogs.

Database Access

This chapter describes how you can take advantage of this capability in your own projects can connect to databases in a universal manner.


This chapter describes how documents contain form controls that are programmed using an event-driven programming model. The Forms chapter shows you how to enhance your documents with controls for data input.


This chapter describes how the Universal Content Broker is the generic resource access service used by the entire office application. It handles not only files and directories, but hierarchic and non-hierarchic contents, in general. Configuration

This chapter describes how the API offers access to the office configuration options that is found in the Tools – Options dialog.


This chapter describes how the OfficeBean Java Bean component allows the developer to integrate office functionality in Java applications. Version History exists in two versions - an open source edition

StarOffice and StarSuite - "branded" editions derived from

In 2000, Sun Microsystems released the source code of their current developer version of StarOffice on, and made the ongoing development process public. Sun's development team, which developed StarOffice, continued its work on, and developers from all over the world joined them to port, translate, repair bugs and discuss future plans. StarOffice 6.0 and 1.0, which were released in spring 2002, share the same code basis.

Related documentation

The api and udk projects on have related documentation, examples and FAQs (frequently asked questions) on the API. Most important are probably the references, you can find them at or

  • The API Reference covers the programmable features of
  • The Java Reference describes the features of the Java UNO runtime environment.
  • The C++ Reference is about the C++ language binding.


This book uses the following formatting conventions:

  • Bold refers to the keys on the keyboard or elements of a user interface, such as the OK button or File menu.
  • Italics are used for emphasis and to signify the first use of a term. Italics are also used for web sites, file and directory names and email addresses.
  • Courier New is used in all Code Listings and for everything that is typed when programming.


A publication like this can never be the work of a single person – it is the result of tremendous team effort. Of course, the development team played the most important role by creating the API in the first place. The knowledge and experience of this team will be documented here. Furthermore, there were several devoted individuals who contributed to making this documentation reality.

First of all, we would like to thank Ralf Kuhnert and Dietrich Schulten. Using their technical expertise and articulate mode of expression, they accomplished the challenging task of gathering the wealth of API knowledge from the minds of the developers and transforming it into an understandable document.

Many reviewers were involved in the creation of this documentation. Special thanks go to Michael Hönnig who was one of the few who reviewed almost every single word. His input also played a decisive role in how the documentation was structured. A big thank you also goes to Diane O'Brien for taking on the daunting task of reviewing the final draft and providing us with extensive feed back at such short notice.

When looking at the diagrams and graphics, it is clear that a creative person with the right touch for design and aesthetics was involved. Many thanks, therefore, are due Stella Schulze who redrew all of the diagrams and graphics from the originals supplied by various developers. We also thank Svante Schubert who converted the original XML file format into HTML pages and was most patient with us in spite of our demands and changes. Special thanks also to Jörg Heilig, who made this whole project possible.

Jürgen would like to thank Götz Wohlberg for all his help in getting the right people involved and making sure things ran smoothly.

Götz would like to thank Jürgen Schmidt for his never-ending energy to hold everything together and for pushing the contributors in the right direction. He can be considered as the heart of the opus because of his guidance and endurance throughout the entire project.

We would like to take this opportunity to thank all these people – and anyone else we forgot! – for their support.

Jürgen Schmidt, Götz Wohlberg

Personal tools