A friend has LibreOffice installed (due to a better mail-merge-support I
understand) and I came up
with a script to help her taking advantage of the writer component. The script
is written in ooRexx
for which I authored an OOo scripting provider that works on OOo, making ooRexx
an additional macro
language for OOo.
Now, installing that package on her machine the scripts work from outside of LO
flawlessly, however
ooRexx does not get registered as another macro language in LO (missing from
the "Macro" menu).
After researching this issue for quite some time now, it turns out that LO
removed a method in
ClassLoaderFactory and changed the signature of the remaining method by
removing the throws clause,
causing a need to compile the script language provider against OOo's
ScriptFramework.jar, if the
script provider is to run against OOo, and having the need to compile it
separately against LO's
version of ScriptFramework.jar, which is a PITA.
In the case that there are other script provider programmers hanging around,
this is what I did in
order to get a single version that runs also against LO, if there is a need to
use
ClassLoaderFactory (maybe in the XScript implementation part):
... cut ...
// instead of: cl = ClassLoaderFactory.getURLClassLoader( metaData );
// load and run the method dynamically at runtime:
Class
clfClz=Class.forName("com.sun.star.script.framework.provider.ClassLoaderFactory");
Class
smdClz=Class.forName("com.sun.star.script.framework.container.ScriptMetaData");
Method meth =clfClz.getMethod("getURLClassLoader", new
Class<?>[]{smdClz} );
cl=(ClassLoader) meth.invoke(null, new Object []{metaData});
... cut ...
Again, this is just a side note for other script provider implementors who get
hit by this LO
pecularity.
Also: in the "description.xml" deployment file make sure that the element
"OpenOffice.org-minimal-version has a value "3.4" or higher (cf.
<https://wiki.documentfoundation.org/Development/Extension_Development>), such
that the extension is
not regarded as "legacy" by LO.
In the end, with the above changes, the ooRexx scripting provider again gets
accepted as a macro
language for LO.
The reference remains OOo, which has been working in all other aspects of the
Macro menu (run, edit,
making the installed macros available etc.) as per the specifications, whereas
LO has some problems
in that area (shared scripts not showing up, listing of the script language in
the menu disappears,
if the menu got used, still user macros remain visible and executable).
---rony
