<The previous article in this series | The table of contents of this series | The next article in this series>
To Know How to Handle (Read or Write) LibreOffice or Apache OpenOffice Writer or Calc Documents via Extensions from Java or Macro Programs
We Create the Manifest File of the UNO Extension File
Now, we will create the manifest file of the UNO extension file, which is a zip file that contains the whole of the UNO extension. The manifest file specifies what UNO data types registry file is included in the UNO extension, and also name a UNO components setting file, which we have created in the previous article.
Ah-ha.
The file is 'resource/'manifest.xml' under the 'source' directory, and write this in the file.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE manifest:manifest PUBLIC "-//OpenOffice.org//DTD Manifest 1.0//EN" "Manifest.dtd">
<manifest:manifest xmlns:manifest="http://openoffice.org/2001/manifest">
<!-- # Change the registry file path -->
<manifest:file-entry manifest:media-type="application/vnd.sun.star.uno-typelibrary;type=RDB" manifest:full-path="thebiasplanet.hiunoextensionsunoextension.uno.rdb"/>
<!-- # Change the components file path -->
<manifest:file-entry manifest:media-type="application/vnd.sun.star.uno-components" manifest:full-path="thebiasplanet.hiunoextensionsunoextension.uno.components"/>
</manifest:manifest>
Um? Um. All right.
We Create the 'Global UNO Service' Instances Factory of the Global UNO Service
In fact, this isn't necessary, but we will create the 'global UNO service' instances factory of the global UNO service that we register into LibreOffice.
You mean 'thebiasplanet.uno.hiunoextensionsunoextension.HiUnoExtensions' by 'the global UNO service that we register into LibreOffice'?
Yes. The global UNO service can be instantiated using the global UNO service manager, and if we do so, this 'global UNO service' instances factory isn't necessary. The 'global UNO service' instances factory is a factory of instances of a specific global UNO service, and is mapped to a static-methods class in Java. As we can get the instance of the global UNO service as a UNO proxy of a specific UNO interface by just calling one of those static methods, it's less cumbersome to get instances of the global UNO service than getting the instance of the global UNO service through the global UNO service manager and then getting the UNO proxy of the specific UNO interface.
Ah-ha.
We create a UNOIDL file, 'unoIdl/thebiasplanet/uno/hiunoextensionsunoextension/HiUnoExtensions.idl', under the 'source' directory, and write this in the file.
// # Change the defined variable name START
#ifndef __thebiasplanet_uno_hiunoextensionsunoextension_HiUnoExtensions_idl__
#define __thebiasplanet_uno_hiunoextensionsunoextension_HiUnoExtensions_idl__
// # Change the defined variable name END
// # Change the interface idl
#include "thebiasplanet/uno/hiunoextensionsunoextension/XHiUnoExtensions.idl"
// # Change the module name
module thebiasplanet { module uno { module hiunoextensionsunoextension {
// # Change the service name and the interface name
service HiUnoExtensions: XHiUnoExtensions {
// # Add constructors START
create1 ( [in] string p_message)
raises (com::sun::star::lang::IllegalArgumentException);
// # Add constructors END
};
}; }; };
#endif
Hmm, is this factory's being named 'thebiasplanet.uno.hiunoextensionsunoextension.HiUnoExtensions' a necessity?
Yes. The name's being the same with the name of the global UNO service name is a necessity: only by the oneness of the two names, the factory is linked to the global UNO service.
I understand.
'#ifndef' ~ '#endif' block is for the code inside it not to be executed multiple times. The name defined can be anything if it's unique from other defined names.
In '#include' directives, <> is used when the included file is under the system include directory, but "" is used when the included file is under a user specific directory.
'XHiUnoExtensions', in full name, 'thebiasplanet::uno::hiunoextensionsunoextension::XHiUnoExtensions', is the return type of factory methods of the global UNO service.
So, we get the instance of the global UNO service as a UNO proxy of the UNO interface type?
If we get the instance through a bridge, yes. Otherwise, the instance is the original UNO component instance itself, not a UNO proxy.
If the UNO component implements multiple UNO interfaces, by specifying one of the UNO interfaces as the return data type, we get the instance in the data type specified. Note, it isn't true that we can create the factory only for a UNO new-style service.
I see.
'create1' is a factory method, which is mapped to a static method in Java. Explanations about arguments and 'raises' clause are the same with the explanations given for the UNO interface. Just be aware that we can't specify '[out]' or '[inout]' for factory methods.
If we want other factory methods, we can add them after the first factory method.
I understand.
Now, we have created all the artifacts we create by hands.
- Apache OpenOffice Wiki. (2014/01/02). Apache OpenOffice Developer's Guide. Retrieved from https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide
<The previous article in this series | The table of contents of this series | The next article in this series>
