On Mar 27, 2005, at 21:35, Christian Junker wrote:
As a side note, compare my Java code to Andrew's SB code ;). And do not ask yourself why I am using such an awkward coding style, I just played around in Eclipse a bit to refresh my Java knowledge.
I think the UNO-Java bridge necessarily leads to less beautiful code. If the Basic runtime can work without queryInterface, why doesn't the Java bridge make the proxy objects implement the exported interfaces right away?
Java is statically typed, while Basic is dynamically typed. That is, in Java the returned type of
o = XSomething.getSomeObject
must be known at compile time so that later calls
o.someMethod()
are accepted. However, the returned type of XSomething.getSomeObject in UNOIDL might be XSomeInterface1, and only additional documentation in the UNOIDL file explains that the returned object will in fact also implement XSomeInterface2, XSomeInterface3, etc., and optionally also XSomeOtherInterface1, ...
This explains why Java UNO needs some sort of dynamic cast here (UnoRuntime.queryInterface or Java's casting mechanism; the choice of the more verbose UnoRuntime.queryInterface over Java's casting mechanism is probably due to a perceived gain in flexibility).
UNO now has features that potentially reduce the need for UnoRuntime.queryInterface dramatically. Over time, the existing OOo UNO API will hopefully be enhanced to make use of those features.
(com.sun.star.beans.XPropertySet) UnoRuntime.queryInterface( com.sun.star.beans.XPropertySet.class, info); xProps.setPropertyValue("Title", getTitle());
Thank you. This bit was what I needed.
Are the supported property set keys documented somewhere?
Yes, in the UNOIDL documentation of the relevant UNO service.
-Stephan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
