As code completion is always available in Tools > Options, and it is
there for a long time, it is no longer relevant to make it visible only
when experimental features are enabled.
Change-Id: I4e80daa92b07745c1bca065c8239df283c69b883
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183171
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins
SbiRuntime::FindElement ends with a call to CheckArray(). The latter
takes a variable, checks if that is an array and if it has parameters;
and if both are true, tries to obtain an element of the array defined
by the parameters as array indexes (using SbxDimArray::Get).
The problem was, that the variable may actually be array; it may have
parameters; but this array can be the result of a function call; the
variable may be SbxMethod; and the parameters may be for the function,
not array indexes.
Specifically, the call like
Iif(True, Array("A","B"), Array("B","A"))
searched for an entity named Iif; found that it was a RTL method;
prepared the arguments for it (consisting of four elements: 0 - the
method itself; 1 - boolean True; 2 - array ["A", "B"]; 3 - array
["B", "A"]); the function executed, putting the correct value to the
params[0], which was the method itself (so its value became an array);
and finally, the SbxMethod variable with the array value got passed
to CheckArray. The latter found out that it's an array, and that it
has parameters (those four) - and tried to get the element, which
index was defined by the parameters.
Here comes the specifics of LibreOffice Basic's argument handling.
SbxDimArray::Get only cares about first arguments expected by the
array dimensions; it ignores the rest. Since the array was single-
dimensional, it only considered parameter 1 (parameter 0 is, by
convention, reserved for return value). That was a boolean. When it
was False, its GetInteger returned 0; and finally, CheckArray took
element 0 from the array, returning a scalar value, as if it was
Iif(False, Array("A","B"), Array("B","A"))(0)
But when the boolean was True, another Basic specific took place:
its numerical value is -1; and trying to get element -1 from the
array resulted in "Index out of defined range".
This change disambiguates between the cases of array index, and
function parameters, checking if the variable itself, and its 0th
parameter are both SbxMethods. Then it doesn't try to treat the
parameters as indexes into the array.
Change-Id: I597f94a7e688c8bba12d87a1bd5871491c25cac0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187145
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The problem is, that there is no definition of resolution of name
visibility, when names are defined in different modules. Before
commit ea2a974386 (Simplify
NameContainer, 2024-12-01), it happened to be the order in which
modules were found in SfxLibraryContainer::init_Impl (it could be
arbitrary in principle).
The said commit changed NameContainer::getElementNames to return
the names in ~arbitrary order (defined by specific unordered_map
implementation).
To workaround the current problem (when 'SBMAXAPPLCOUNT' defined
in 'DialogModul' of 'ImportWizard' library is not visible in its
'Language' module at library load time, specifically on Linux),
just sort the library element names at its loading time. It will
not create performance problem (it is a one-time sort over a small number of elements; having millions of modules in a single library
is not realistic, and would create bigger problems elsewhere).
Change-Id: I93e91ae5f4be12a1bf641fe2d29e0a161589b8af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187081
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Resetting parameters in this function was introduced in commit
0b21b8b146 (initial commit for vba blob
( not including container_control stuff ), 2010-10-06). Unfortunately,
the reason for that is not explained.
The problem that it creates is that this code gets called eventually
from SbiRuntime::FindElement (which sets parameters using SetupArgs,
then calls SbiRuntime::CheckArray in the end, which calls GetObject,
which performs actual data access).
In SbiRuntime::CheckArray, the immediate problem was, that parameters
were referenced using a raw pointer; when the parageters were cleared
in GetObject, the pointer got dangling.
But it wasn't enough to use e.g. SbxArrayRef there, to keep the array
alive; the object will be accessed later, and needs its parameters to
work. On the other hand, it feels wrong to reinstate parameters after
the call to GetObject in SbiRuntime::CheckArray (getting the object
can run just any code path). So I chose to try and drop the resetting
of parameters in SbUnoObject::Notify. Let's see, if something breaks.
Change-Id: Icadfcfb8b7e5e87b2de46166963fd97532f8713c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186432
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
For numeric types, they are made unified templates. In many cases,
gotos were dropped, and the code was streamlined. Hopefully, this
would make it at least a bit manageable.
Change-Id: I63154d61fa6629d1431157ac382ec758f4f50074
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186234
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit 81e1e0a2a6 changed string-to-number
procedure from SvNumberFormatter to only use SbxValue::ScanNumIntnl. But
the latter can only handle strings with simple numbers, not with dates,
times and the like.
This change restores use of SvNumberFormatter to convert input strings
to number, when SbxValue::ScanNumIntnl fails. The code is re-structured
for performance, to avoid creating SvNumberFormatter twice, and repeated
calls to GetOUString.
Change-Id: I89a4fc041fe24fe00b099ab4fbee371d1f6b5567
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185047
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Avoids the need to convert between OUString and OString;
and resolves a pressing Win16 compatibility issue.
Change-Id: I4cf5b6962050181a66a33c1261c9440ac7a39b82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183487
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
found by a little plugin I created.
Plugin parked into store/ folder because it needs hand-holding
when run.
Change-Id: I2b4da7378f0becbc5f020ac9e78cd765aa0119b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181768
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
If BASIC function NOW is called with the wrong number of arguments,
then return error code 5 (Invalid procedure call).
Change-Id: I123f316e36e6726a2cfc9d1e53664ce632af1289
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181303
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
these are always XStorageBasedLibraryContainers, so transport
around as that and can avoid casting and some expensive throw/catches
Change-Id: I772efceea3bb4f38d70be0497345f5f81173494c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181156
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Since the initial import, there is a code in SbiExpression::Term, that
checks if the defined symbol is used as object (e.g., dot notation to
access its members), and then, if its defined type is Variant, then it
is corrected to Object. There is no rationale for this in comments; so
I have no way to know what could break if that core is dropped.
It's obvious that at least for procedure arguments, such correction is
wrong: the argument definition is the procedure's API; and the actual
use of the symbol should not unexpectedly change what is advertised.
This change limits the application of the correction to non-arguments.
If it should be dropped completely is a separate question.
Change-Id: Ia902afa3f744d0d51510ba6903be45f78e2f6429
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180665
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Commit 9cdb73ff28 (INTEGRATION: CWS jl5vba
(1.25.94); FILE MERGED, 2004-03-17) has introduced handling of decimal,
currency, and date for VBASupport mode in sbunoobj.cxx. However, in
getUnoTypeForSbxBaseType, it changed the behavior for date type in the
non-VBASupport mode, obviously by mistake. This change swaps the code
in the 'if' branches, to what appears to be the original intention.
Change-Id: I88cddf7cec1a980f56de96ae1c5e64d8e7630b77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180637
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Hossein