This is in preparation of moving code out of weld.hxx
to separate headers/source files, in order to make it
easier to keep an overview and to avoid having to
recompile ~all UI code when anything changes.
Also move weldutils.cxx to a new vcl/source/weld
directory.
Change-Id: Ia75b42f21e560dd248307282a522f186a64cd742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195777
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Replace traditional SbxParams::const_iterator loop with modern range-based
for loop in SbxVariable::GetName() for better readability and modern C++
style while preserving the comma-separation logic between parameters.
Change-Id: Ib978b29b70bf6a0a85bf94be1a3dd67fea45529d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193379
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
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>
1. If a string is passed as argument, it is returned without any changes.
For that, SbRtl_Str checks argument type, skipping processing for string.
2. Non-negative numbers are preceded by a blank space.
That already was implemented.
3. Negative numbers are preceded by a minus sign.
That was done incorrectly - a space was added for any number.
4. Dates are converted into locale-dependent strings.
That wasn't done at all - dates were converted to strings representing
the serial date. A check is implemented SbxValue::Format, to handle this.
Additionally, Format function was improved to handle such input without
format string (taking into account that it handles strings that can be
converted to numbers differently).
Change-Id: I5ac0429950e4ea8bf69b0091502b4e6dc1f4957d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191549
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
testTdf149157_continuation_in_comment_after_new_line* and
testTdf149402_continuation_in_comment_ending_with_whitespace*
to make it easier to understand what they are testing.
Change-Id: I6be5883d6cb837ecf2d3208ea1b7c1dabaaec070
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191397
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
Flattens function implementations by returning early when an argument
check fails rather than using if/else blocks.
Change-Id: I5adad466e41ac95ad5bde43d758babf5932ec304
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187606
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
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>
When a value is convertible to number, check if the format string
is for numbers of text (in SbxValue::Format). If the value is not
convertible to number, handle it according to the format string in
printfmtstr.
Change-Id: I6e11aeffd8dd8581ebc868762944e9d6d9393514
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190348
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
places where we are constructing a Graphic by first
converting to BitmapEx, which is unnecessary, rather pass a
Bitmap to Graphic.
Change-Id: I386f68e7f5bc6ef9509352187dbe9a0774defaac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190307
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
Michael Weghorn