Difference between revisions of "Documentation/DevGuide/WritingUNO/Using the UNO Executable"
m |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 5: | Line 5: | ||
|NextPage=Documentation/DevGuide/WritingUNO/Accessing Dialogs | |NextPage=Documentation/DevGuide/WritingUNO/Accessing Dialogs | ||
}} | }} | ||
| − | + | {{Documentation/DevGuideLanguages|Documentation/DevGuide/WritingUNO/{{SUBPAGENAME}}}} | |
{{DISPLAYTITLE:Using the UNO Executable}} | {{DISPLAYTITLE:Using the UNO Executable}} | ||
The main benefit of using the ''uno'' tool as a replacement for writing executables is that the service manager initialization is separated from the task-solving code and the component can be reused. For example, to have multiple XMain implementations run in parallel in one process. There is more involved when writing a component compared to writing an executable. With the bootstrap variable mechanism there is a lot of freedom in bootstrapping the service manager (see chapter [[Documentation/DevGuide/ProUNO/C++/C++ Language Binding|C++ Language Binding]]). | The main benefit of using the ''uno'' tool as a replacement for writing executables is that the service manager initialization is separated from the task-solving code and the component can be reused. For example, to have multiple XMain implementations run in parallel in one process. There is more involved when writing a component compared to writing an executable. With the bootstrap variable mechanism there is a lot of freedom in bootstrapping the service manager (see chapter [[Documentation/DevGuide/ProUNO/C++/C++ Language Binding|C++ Language Binding]]). | ||
| Line 11: | Line 11: | ||
The ''uno'' tool is a good starting point when exporting a certain component as a remote server. However, when using the UNO technology later, the tool does have some disadvantages, such as multiple objects can not be exported or the component can only be initialized with command line arguments. If the ''uno'' tool becomes insufficient, the listening part in an executable will have to be re-implemented. | The ''uno'' tool is a good starting point when exporting a certain component as a remote server. However, when using the UNO technology later, the tool does have some disadvantages, such as multiple objects can not be exported or the component can only be initialized with command line arguments. If the ''uno'' tool becomes insufficient, the listening part in an executable will have to be re-implemented. | ||
| − | {{ | + | {{Note|To instantiate Java components in build version 641, you need a complete setup so that the uno executable can find the java.ini file.}} |
{{PDL1}} | {{PDL1}} | ||
[[Category:Documentation/Developer's Guide/Writing UNO Components]] | [[Category:Documentation/Developer's Guide/Writing UNO Components]] | ||
Latest revision as of 14:49, 4 July 2018
- Standalone Use Case
- Server Use Case
- Using the UNO Executable
The main benefit of using the uno tool as a replacement for writing executables is that the service manager initialization is separated from the task-solving code and the component can be reused. For example, to have multiple XMain implementations run in parallel in one process. There is more involved when writing a component compared to writing an executable. With the bootstrap variable mechanism there is a lot of freedom in bootstrapping the service manager (see chapter C++ Language Binding).
The uno tool is a good starting point when exporting a certain component as a remote server. However, when using the UNO technology later, the tool does have some disadvantages, such as multiple objects can not be exported or the component can only be initialized with command line arguments. If the uno tool becomes insufficient, the listening part in an executable will have to be re-implemented.
 |
To instantiate Java components in build version 641, you need a complete setup so that the uno executable can find the java.ini file. |
| Content on this page is licensed under the Public Documentation License (PDL). |
