What This Manual Covers

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

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

How This Book is Organized

Every page of this book has a Table of Contents at the right side of the page. This TOC shows the content of the current part and navigation links to browse parts and pages of this book.

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 OpenOffice.org applications.

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.

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 the service manager. Before beginning this chapter, you should be familiar with the First Steps and Professional UNO chapters.

This chapter describes the various aspects of OpenOffice.org Extensions. It explains the specifics of how Extensions can be developed, and provides an overview of the various things that you must do to develop your own Extension.

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

This chapter describes how OpenOffice.org 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.

This chapter is for extension developers who want to add functionality to their OpenOffice.org application and want to create a consistent user interface. It explains how you can add your own GUI to your OpenOffice.org applications.

OpenOffice.org Version History

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

The Java Reference describes the features of the Java UNO runtime environment.

The C++ Reference is about the C++ language binding.

Conventions

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.

Acknowledgments

A publication like this can never be the work of a single person – it is the result of tremendous team effort. Of course, the OpenOffice.org/StarOffice 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.