Difference between revisions of "Documentation/DevGuide/WritingUNO/Implementing Your Own Interfaces"
m (1 revision(s)) |
|||
| Line 68: | Line 68: | ||
For the component to run, the new interface class file must be accessible to the Java Virtual Machine. Unlike stand-alone Java applications, it is not sufficient to set the CLASSPATH environment variable. Instead, the class path is passed to the VM when it is created. Prior to {{PRODUCTNAME}} {{OO1.1.0}}, one could modify the class path by editing the <code>SystemClasspath</code> entry of the ''java(.ini|rc)'' which was located in the folder ''<officepath>\user\config. ''Another way was to use the Options dialog. To navigate to the class path settings, one had to expand the {{PRODUCTNAME}} node in the tree on the left-hand side and chose '''Security'''. On the right-hand side, there was a field called '''User Classpath'''. | For the component to run, the new interface class file must be accessible to the Java Virtual Machine. Unlike stand-alone Java applications, it is not sufficient to set the CLASSPATH environment variable. Instead, the class path is passed to the VM when it is created. Prior to {{PRODUCTNAME}} {{OO1.1.0}}, one could modify the class path by editing the <code>SystemClasspath</code> entry of the ''java(.ini|rc)'' which was located in the folder ''<officepath>\user\config. ''Another way was to use the Options dialog. To navigate to the class path settings, one had to expand the {{PRODUCTNAME}} node in the tree on the left-hand side and chose '''Security'''. On the right-hand side, there was a field called '''User Classpath'''. | ||
| − | As of {{PRODUCTNAME}} {{OO1.1.0}} the component, class files, and type library are packed into a extension, which is then registered by the ''pkgchk'' executable. And as of {{PRODUCTNAME}} {{ | + | As of {{PRODUCTNAME}} {{OO1.1.0}} the component, class files, and type library are packed into a extension, which is then registered by the ''pkgchk'' executable. And as of {{PRODUCTNAME}} {{OO2.0.0}}, the unopkg tool is used to do this. The jar files are then automatically added to the class path. |
{{Documentation/Note|It is also important that the binary type library of the new interfaces are provided together with the component, otherwise the component is not accessible from {{PRODUCTNAME}} Basic. Basic uses the UNO core reflection service to get type information at runtime. The core reflection is based on the binary type library.}} | {{Documentation/Note|It is also important that the binary type library of the new interfaces are provided together with the component, otherwise the component is not accessible from {{PRODUCTNAME}} Basic. Basic uses the UNO core reflection service to get type information at runtime. The core reflection is based on the binary type library.}} | ||
Revision as of 07:48, 13 March 2008
- Class Definition with Helper Class
- Implementing Your Own Interfaces
- Providing a Single Factory Using a Helper Method
- Write Registration Info Using a Helper Method
- Implementing without Helpers
- Storing the Service Manager for Further Use
- Create Instance with Arguments
- Possible Structures for Java Components
- Running and Debugging Java Components
The functionality of a component is accessible only by its interfaces. When writing a component, choose one of the available API interfaces or define an interface. UNO types are used as method arguments to other UNO objects. Java does not support unsigned integer types, so their use is discouraged. In the chapter Using UNOIDL to Specify New Components, the org.openoffice.test.XImageShrinkFilter interface specification was written and an interface class file was created. Its implementation is straightforward, you create a class that implements your interfaces:
package org.openoffice.comp.test;
public class ImageShrink extends com.sun.star.lib.uno.helper.WeakBase
implements com.sun.star.lang.XServiceInfo,
org.openoffice.test.XImageShrinkFilter {
...
String destDir = "";
String sourceDir = "";
boolean cancel = false;
com.sun.star.awt.Size dimension = new com.sun.star.awt.Size();
// XImageShrink implementation (a sub-interface of XImageShrinkFilter)
public void cancel() {
cancel = true;
}
public boolean filter(com.sun.star.beans.PropertyValue[] propertyValue) {
// while cancel = false,
// scale images found in sourceDir according to dimension and
// write them to destDir, using the image file format given in
// []propertyValue
// (implementation omitted)
cancel = false;
return true;
}
// XIMageShrink implementation
public String getDestinationDirectory() {
return destDir;
}
public com.sun.star.awt.Size getDimension() {
return dimension;
}
public String getSourceDirectory() {
return sourceDir;
}
public void setDestinationDirectory(String str) {
destDir = str;
}
public void setDimension(com.sun.star.awt.Size size) {
dimension = size;
}
public void setSourceDirectory(String str) {
sourceDir = str;
}
...
}
For the component to run, the new interface class file must be accessible to the Java Virtual Machine. Unlike stand-alone Java applications, it is not sufficient to set the CLASSPATH environment variable. Instead, the class path is passed to the VM when it is created. Prior to OpenOffice.org 1.1.0, one could modify the class path by editing the SystemClasspath entry of the java(.ini|rc) which was located in the folder <officepath>\user\config. Another way was to use the Options dialog. To navigate to the class path settings, one had to expand the OpenOffice.org node in the tree on the left-hand side and chose Security. On the right-hand side, there was a field called User Classpath.
As of OpenOffice.org 1.1.0 the component, class files, and type library are packed into a extension, which is then registered by the pkgchk executable. And as of OpenOffice.org 2.0, the unopkg tool is used to do this. The jar files are then automatically added to the class path.
| Content on this page is licensed under the Public Documentation License (PDL). |
