The arguments for a macro when invoked by the dispatch provider get
converted from a set of PropertyValues to a sequence of Anys containing
just the values. Since the commit below, the TransformItems step was
changed to store the PropertyValues in an unordered_map which makes the
order of the values unpredictable. If the dispatch provider is used to
execute a macro then the order of the arguments becomes important
because the macro has no other way to determine which argument
represents which property. In order to maintain the previous behaviour,
the dispatch method now reorders the arguments so that they have the
same order as before. The previous order was determined by the order the
properties were handled in TransformItems.
commit e8d73d5307
Author: Mike Kaganski <mike.kaganski@collabora.com>
Date: Wed Dec 3 10:45:35 2025 +0500
Let TransformItems return comphelper::SequenceAsHashMap
Simplifies its usage in all places where the result needs to be
modified.
Change-Id: I37f8d99827e0f1cb2b6e4f4f7735e26fb87f6703
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195162
Change-Id: Iacf64650842eb62c0a2bd266784aa9c7accf45bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209231
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Adds a Python unit test that just tries to retrieve all child nodes from
the master script provider in order to check that they are all
accessible from Python.
Change-Id: I97185b7f21f38a79fdda4078a69d8e88b10cbaed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207349
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
The base script provider in Java for several languages was throwing an
exception when trying to rename an empty library. The browsenodes member
variable was being lazily created when getChildNodes was called but in
the case where there were no children it was being left as null which
was causing a Java runtime exception.
Change-Id: I0d9eac2006bc26d47c22f2e1a7a4424fd67a512f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207152
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tests that it correctly reads the filesystem to find files, the
Creatable and Editable properties work and that it can execute a script.
Change-Id: I613cf539f256c1ba464fa523f431fcf6e95da5f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204519
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Adds an XBrowseNode implementation for JavaScript scripts using the
QuickJS bindings so that JS files can be found and executed from the
macro organizer. Unlike in Python macros, the entire source file becomes
a single macro instead of trying to find function definitions in the
source.
Change-Id: I73d0c6e6fc6bb7ffd4f6164d1f1887d03bfdfe62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203219
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Adds a set of helpers to implement a script provider where the script
files are the entire macro. The provider only needs to make a subclass
of the abstract SingleScriptFactory class to provide the filename
extension, language name and a method to convert the contents of a file
to an XScript. The parts about handling file browsing and reading the
file contents are in the shared helper code.
This is based on the script provider from Luno.
Change-Id: Id39f3a07e887898650b0d77ec493011fb5acc858
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203216
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Unfortunatly we cannot add --disable-scripting to
sub_conf_defaults, because Java currently has no
equivalent to the PYTHON_FOR_BUILD setting.
Change-Id: I89938a17307a363f5de808200914940503312829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126186
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Feature test macros that govern conditional compilation should be
defined in config_*.h include files, not on the compilation command
line.
Change-Id: I40575a4762fd2564f10927b6f38a112dd9f9a3d7
To avoid unnecessary confusion between the newly plain code and any instance of
the old extension still installed (per-user or shared), I renamed the UNO
implementation identifier org.openoffice.pyuno.LanguageScriptProviderForPython
to org.libreoffice.pyuno.LanguageScriptProviderForPython. Also, existing
installations of the extension are explicitly not migrated to new user profiles.
Change-Id: Id3dd66ba5e52e0962f7ad0ccb5e4ad5b0bec97fa
Any LO-based app distributed through the App Store can't have
scripting or extendability anyway.
Sure, this will break the build elsewhere because of missing headers.
No big deal, I will take care of that eventually. It isn't as if there
would anybody else building for iOS anyway, as far as I know. If there
is, please make yourself heard.
Their jar files reference other non-URE jars, so they cannot be extensions.
bsh.jar has been moved into the optional module (it used to be installed
always, but it looks like only the bsh script provider needs it; also, it
had been added to URE_MORE_JAVA_CLASSPATH_URLS if SYSTEM_BSH, which also
appears unnecessary as it is mentioned with an absolute file URL in the
Class-Path of the script provider jar).
js.jar has been included in the optional module (it used to be not installed
at all?).
Neil Roberts