Lars’s Blog

Before OpenOffice version 2.x the only possible way to automate OpenOffice was using
Reflection. Okay, it was possible but it was not elegant and there were many hidden traps by using
the UNO api through reflection and COM interop. Since version 2.x OpenOffice offers the CLI UNO bindings
as .net assemblies and much of the work that was difficult before is much more easier now. Only add the
CLI assemblies to your .net project and start developing. However, also with the new assemblies
there were a large count of new questions. Since over one year I’ve recieved dozens of questions about
OpenOffice automation with C# using the CLI UNO assemblies. Most of them occour while starting the first
application and seeing that most of the code offered by the CLI assemblies are only interfaces. Yes,
that’s the design principle of the OpenOffice API it based on interfaces and as developer you have to program
against interfaces and some of them you have to implement. So far so good, this shouldn’t a real problem for most of the
.net developer. The problem is to find out how the interfaces works together.

A good starting point for finding answers to your questions is the OpenOffice Developer Guide. Over 1100 pages
really cover all areas of client and UNO component development. A small disadvantage for pure .net developer would
be that there are only a few pages about the CLI UNO bindings with a few example codes. If you have a good knowlegde
of C++ or Java, you should be able to port the dozens of examples from the other chapters to .net. If not,
programming with the CLI UNO bindings could become a very hard job.

In the OOforum.org where I answered dozens of questions about programming for OpenOffice with .net, I saw many good
ideas about integrating OpenOffice into .net based software. Some of these ideas died , because of the lack
of information about OpenOffice programming with .net. This often results in an high expenditure of time which
in turn isn’t acceptable by the project leader and or the customer.

I really believe in OpenOffice and think that it is a good idea to use OpenOffice automation instead of MS Office.
OpenOffice is not only free avalaible it also offers the same comfort for end users and developers as MS Office (My opinion ).
For making OpenOffice client developing easier in the future I decieded to write a free (LGPL) .net 2.0 library (CLI_UNO_EX).
The most importent intentions of CLI_UNO_EX are to hide the real complexity of the UNO implementation, to simplify
often used tasks and to be well documented. Whereby hiding not mean that the CLI_UNO_EX close the “door” to the access
of the UNO objects! It use the wrapper pattern to encapsulate the different types of UNO objects therefor it implements the
required UNO interfaces of these objects and can offer you so to program against real classes instead of interfaces.
For showing you the differences take a look at the following examples which shows you the loading and displaying of
a document. First by using CLI assemblies only and second by using CLI_UNO_EX.

1. CLI assemblies only

unoidl.com.sun.star.uno.XComponentContext localContext =
 uno.util.Bootstrap.bootstrap();

unoidl.com.sun.star.lang.XMultiComponentFactory multiComponentFactory =
 (unoidl.com.sun.star.lang.XMultiComponentFactory) localContext.getServiceManager();

XDesktop desktop =
 (XDesktop) multiComponentFactory.createInstance(
 "com.sun.star.frame.Desktop" );

XComponent xComponent = ((XComponentLoader)desktop.loadComponentFromURL(
 "file:///D:/MyDocs/some_doc.odt", "_blank", 0, new unoidl.com.sun.star.beans.PropertyValue[0]);

2. By using CLI_UNO_EX

ComponentContext componentContext = Bootstrap.bootstrap();

Desktop ooDesktop = new Desktop(componentContext);

Component component = ooDesktop.LoadComponentFromURLEx(@"D:MyDocssome_doc.odt", "_blank", 0, new Hashtable());

When comparing these two examples you can see that in the CLI only version you have to know which object
offer which interfaces as in the CLI_UNO_EX version you don’t see any type casts. These casts will be all
done automaticaly in the library. Of course also by using the CLI_UNO_EX library you have to know
which class offer the features you are looking for, but this can be simply taken from the documentation. All
classes, properties and methods are documented. As I said before the access to the UNO objects isn’t
closed and all CLI_UNO_EX classes offers access to the UNO objects they encapsulates via a public property.
Also through the fact that they implements the UNO interfaces they can be simply be casted to these types.
This will then look smilar as shown in the first example.
While comparing the document load methods loadComponentFromURL and LoadComponentFromURLEx you see more
features. The loadComponentFromURL require the path in the url file format as the LoadComponentFromURLEx
method accept it in the standard Windows format. The library offer a public Path helper class which can be
used to convert file pathes into formats required by UNO / OpenOfffice. At least you can see that the
last parameter is a simply .net Hashtable instead of an UNO PropertyValue object. Also for this
conversion the library offer a converter class.

And where can I download the library? Up to now there is no downlad package. The library is only avalaible through SVN.
You can check out the latest version from the following URL (https://aodl.svn.sourceforge.net/svnroot/aodl/CLI_UNO_EX).
Or you can browse the repository online within this URL
Browse SVN.



Notice: The library is an early development state and shouldn’t be used within important projects. I can’t
guarantee that there are no major changes in future versions which wont be compatible with this version.


For any kinds of questions use the forum. To get to the forum click here.