octave-maintainers
[Top][All Lists]
Advanced

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]