this was skipped in previous runs, since it contains some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: If1e3e3c7c0fc14ed6e8b51174a0e7f1220fdbc8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197496
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
The *32 methods were initially introduced in a series of "Basic Modules > 64K"
commits (2003), in addition to the pre-existing [GS]etSource methods. Then, in
commits d41b8ac9e5 (callcatcher: shave off a few
more, 2015-02-02) and 919375354c (GetSource32
and GetSource are identical, 2019-12-09), the original methods were dropped.
Now the '32' suffix to the methods makes no sense.
Change-Id: I9dc172ce973b1b49511518f184d174ea68227cdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192086
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The problem appeared, when a macro loaded a library with a class module,
that had a public element (e.g., a function) with the same name, as used
for a local variable in the macro without a prior DIM.
Normally, there is a precaution in SbModule::Find, which hides the names
in class modules. However, this precaution failed during load.
The reason was, that the flag identifying the module as a class module
was set only when the module got compiled. It turned out, that first, it
is parsed in SbModule::SetSource32 only partially, with minimal work to
recognize the names (and a few other small things). At this stage, it is
not marked as class module yet; and when the clashing name is looked up,
it gets found in the module. Then its value is requested; at this point,
the module gets compiled, and the "class module" flag is set; then, if
the class module element tries to use another name from the same module,
it fails, which produces visible error message.
This change makes sure, that the initial fast parse stage also checks
Option ClassModule, to set it properly. Also it drops redundant variable
bIsProxyModule from SbModule, because mnType already contains the needed
type information. And lastly, it reorders SbModule::Find a bit, to avoid
searching a module, only to discard the result immediately, because it's
a class module.
Change-Id: I8add9873bf31fb767b64d27a36aef8e3a89a0de0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192075
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
I added the code that I remove here in commit
22d7827c66 (tdf#168569: support date
values in string pool, 2025-09-26), but this is section to handle
old images, after commit 3bcfb1aac1
(tdf#143707 - Change strategy to support suffix type characters,
2021-08-10) the suffixes are written in a way that is handled in
SbiImage::GetString.
Change-Id: Ia2ad05f1e146dc40686f2baf07f178331f1ff4a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191561
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Commit f45463d8e2 (tdf#93727 Support date
literals in basic, 2017-05-24) introduced correct parsing of literals
like #2025-09-26#. However, it didn't retain the value type; there was
a discussion about that in gerrit, but no solution was found, and type
was set to double.
Later, a similar problem (storing type of value in compiled image) was
fixed in commit 5eedb3beea (tdf#142460:
properly handle boolean values in string pool, 2021-06-25).
This change reuses the same method to store date type using 'd' char in
the string pool.
Change-Id: I32e8497ece1f30980ba6d4fca248687b817348f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191555
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Without that, there is no code to deliver that value. The call to
SbxValue::Get will eventually get to the SbUnoObject containing a
css::bridge::oleautomation::Date in struct info; and there it will
find that the object's SbxValue points to itself, at which point,
it will error out from SbxValue::TheRealValue.
Change-Id: Ia08fb2a7b1bcd7292faf5a5719a4fad0054a3f5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190384
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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
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
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>
There is no general solution to this that I am aware of, so just
implement a rather specific solution that will need periodic extending
to check for other dangerous properties
Change-Id: Ie09d89416fea5b7cdf782319ed9921657faa5a5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176593
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Don't silently convert missing parameters including their error code to the request target typen when the target type can't handle the conversion.
Change-Id: I2300aa594ae3cc1045a6397c1195718b6662aa61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172593
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
Gabor Kelemen