<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
The UNO Proxy Is Created for the Return Type UNO Interface of the Method
We have already learned what UNO proxies are, but there is a thing we have to be aware of.
Ah-ha.
The UNO proxy is created for the return type UNO interface of the method.
. . . I don't understand very well. What method do you mean?
Let's think with an example. There is a programming language environment, PLE-A, and a UNO object, UO-A-A0, lives in PLE-A; there is another programming language environment, PLE-B, and we are handling UO-A-A0 from PLE-B through a bridge. UO-A-A0 has a method that creates and returns a UNO object, UO-A-A.
OK.
The return type of the method is specified as a UNO interface, UI-Z.
All right.
When we call the method from PLE-B, the bridge transmits the return operation, and a UNO proxy, UP-B-A-UI-Z, is created and returned to us. The proxy, UP-B-A-UI-Z, represents only the UNO interface, UI-Z, which means, the proxy has only methods of UI-Z.
So, even if the UNO object, UO-A-A, implements another UNO interface, UI-Y, we can't call methods of UI-Y on our UNO proxy UP-B-A-UI-Z. . . . What if we want to call methods of UI-Y?
There is a utility class method, 'com.sun.star.uno.UnoRuntime.queryInterface', that takes a UNO proxy we already have, and gives us a UNO proxy of our desired UNO interface, if, of course, the original UNO object implements the UNO interface.
Oh.
By the way, I don't understand explanations about this matter in the 'First UNO' part of the reference documents. It says, we can't cast the return of the method to another UNO interface type (in the aforementioned case, from UI-Z to UI-Y) because the compiler doesn't know that the returned object is an object of the UNO interface (in the aforementioned case, UI-Y).
Huh? That's odd. In Java, we cast an object to a type because the compiler doesn't know that the object is an object of the type. That's the concept of type casting in Java. If the compiler already knows it, we don't have to teach it to the compiler by type casting. The Java compiler isn't such unintelligent or unkind as it requires a type casting when it already knows that the object is an object of the type.
I wasted much time trying to understand what those explanations mean.
. . . As far as I see, those explanations seem to have become such because the author tried to explain without introducing the concept of proxy. I assume that the author was much better informed on UNO than we are, but those explanations are confusing. The author might have thought that the concept of proxy would confuse readers, but inaccurate descriptions confuse readers more.
As a lesson, we should take care not to describe things inaccurately to smooth things over for the moment.
By the way, this isn't particularly a recommendation, but in fact, we can cast directly the returned object to a UNO interface when the method call isn't through any bridge. In that case, the returned object isn't a UNO proxy, but the UNO object itself, so, we can cast it directly to a UNO interface type implemented by the UNO object.
That's a natural conclusion if we understand the mechanism correctly.
What Is UNOIDL (UNO Interface Definition Language)? What Is the UNO Data Types Registry?
As UNO is 'programming language'-independent, UNO data types including UNO interfaces have to be recognized by all the programming languages that support UNO. So, we need to register UNO data types in a 'programming language'-independent form. The registry that contains such UNO data types is the UNO data types registry.
Hmm, that explanation seems plausible at first glance, but it isn't really convincing. When we access a UNO object that lives in a C++ environment from a Java environment, we need a UNO interface as a Java interface; otherwise, we can't even compile our Java programs. While we can recognize the UNO data type by the Java interface, do we need a UNO data type in the 'programming language'-independent form?
Well, honestly, I don't know. We can't test it right now because we don't develop UNO extensions in C++. However, at least, LibreOffice Basic macros seem to need it.
I understand that registering UNO data types in a 'programming language'-independent form doesn't harm anything, but the unclearness of the mechanism makes me uneasy. Why don't we create a C++ UNO extension, and test it, sometime?
OK. Sometime.
Anyway,we define UNO data types in a UNO specific definition language, which is UNOIDL, and compile UNOIDL source files to UNO data types unmerged registry files, which we can merge into a UNO data types merged registry file. Using the UNO data types merged registry file, we can register our UNO data types into the UNO data types registry of LibreOffice.
How exactly do we use the UNO data types merged registry file?
We can include the file in a UNO extension file and make the UNO extension manager register the UNO data types into the UNO data types registry, or we can register the file itself into the UNO data types registry. We did the former in our sample UNO extension; we will do the latter in a future article.
By the way, we can generate UNO interfaces as Java interfaces from the UNO data types merged registry file using a UNO tool. So, we don't need to write Java source files for UNO interfaces as Java interfaces.
I see.
- 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>
