openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Seidel <>
Subject Re: Just a little side note on the scripting framework ...
Date Thu, 14 Jun 2018 20:54:28 GMT
Hi Rony,

Am 14.06.2018 um 20:54 schrieb Rony G. Flatscher (Apache):
> 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
> language for OOo.

That's very interesting!
I know Object Rexx from my times with OS/2 (in fact I am still running
it in a VM).
Is your scripting provider available somewhere?


> Now, installing that package on her machine the scripts work from outside of LO flawlessly,
> ooRexx does not get registered as another macro language in LO (missing from the "Macro"
> 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
> 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("");
>           Class smdClz=Class.forName("");
>           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
> " has a value "3.4" or higher (cf.
> <>), 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
> if the menu got used, still user macros remain visible and executable).
> ---rony

View raw message