[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with unwanted auto-boxing Java objects in 3.7.1+
From: |
PhilipNienhuis |
Subject: |
Problems with unwanted auto-boxing Java objects in 3.7.1+ |
Date: |
Fri, 25 Jan 2013 13:46:19 -0800 (PST) |
(ref:
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-December/031429.html)
While trying to convert the io package spreadsheet scripts to work with the
new built-in Java interface in 3.7.1+, I hit a bit of a showstopper with the
UNO interface (LibreOffice/OpenOffice.org) scripts:
After a bit of fiddling with various LibreOffice Java calls and objects, the
following call is used in an io package script meant for opening a
LibreOffice spreadsheet file:
xComp = aLoader.loadComponentFromURL ("private:factory/scalc", "_blank", 0,
lProps);
(where aLoader is a <java_object> of class $Proxy3 in 3.7.1+, or octave_java
class in 3.6.4-rc1.)
In 3.6.4-rc1 with the OF Java package, the above call returns xComp as a
Java object (class octave_java).
However, in 3.7.1+ xComp now gets casted to a plain Octave (empty) double.
Doubles are not amenable for the next Java method call in line:
xSpdoc = xComp.queryInterface (unotmp)
Trying to rewrite the offending line into:
xComp = javaMethod ("loadComponentFromURL", aLoader, ...
"private:factory/scalc", "_blank", 0, lProps)
doesn't help: still I get an empty double.
How can the proper class of xComp be retained / obtained? or, IOW, is there
a way to avoid auto-boxing of Java Objects?
Thanks,
Philip
--
View this message in context:
http://octave.1599824.n4.nabble.com/Problems-with-unwanted-auto-boxing-Java-objects-in-3-7-1-tp4649108.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.
- Problems with unwanted auto-boxing Java objects in 3.7.1+,
PhilipNienhuis <=