Don't execute On expression GoSub Statement; On expression GoTo
Statement if the expression lies out of range.
Change-Id: I5c1de25918b5e812d7ec82034f8d56351374d56a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165960
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
- vcl change UNO type of UnoGraphicProperty::BitsPerPixel to sal_Int8 instead of sal_uInt8 which maps to BOOLEAN causing Basic to convert
non-0 values to True
- basic add CppUnitTest since thats where the problem was occuring
Change-Id: I0111199151fb5e001b6362e1359ad90bb039f064
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163899
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Previously, BASIC CCur used a custom, single-purpose currency string
parser which did not properly accommodate the user's locale setting.
This change replaces the custom parser with SvNumberFormatter, which
does correctly respect system locale.
Change-Id: I179915eb080e876e5e550dd350fdb86d7fa2bf4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160848
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Exponent in scientific number may use '?' as blank like in format "0.00E+?0"
This change:
- adds interpreatation of '0' and '?' in exponent
- adds "blank-exponent-digits" attribute to scientific number for import
and export to ODF
- prevents using exponent with only '?'. There must be at least one '0'
in exponent
- adds QA test of such format and test import/export/import to ODF and OOXML
- corrects one basic test
Change-Id: If52edc632a161f842270bb2fd77af535e2b978d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154986
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Instead of returning ErrCode class everywhere, return a new
class ErrrCodeMsg, which combines an ErrCode with the other
parameters that are used to control the error reporting.
I do not change everything that uses ErrCode here, I started
from SfxBaseController/SfxMedium and worked outwards.
This change serves two purposes
(1) Replace the extremely whacky ErrorInfo mechanism we were
using to smuggle information into the error handler reporting
mechanism with a very straightforward approach of just combining it
into the error class.
(2) Allow us to capture the source location that produced the error,
which makes debugging the source of a problem soooo much easier.
Change-Id: I978b8f00c9851b41a216c7ebdef2ef94251d5519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157440
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This properly handles null bytes that are expected
when converting between byte strings and Unicode.
It properly handles TransliterationFlags, which are
not a bitset.
In vbProperCase, it uses the correct method to
lowercase the string, working not only with ASCII.
Change-Id: I04e8cdca66ef9863a6516b15205a2a543ed97680
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149224
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Building CppunitTest_basic_macros using VS2022 failed for me reproducibly
for some time, with
make[1]: *** [C:/lo/src/core/solenv/gbuild/LinkTarget.mk:841: C:/lo/src/build/workdir/LinkTarget/CppunitTest/test_basic_macros.dll] Error 139
It is caused by linking odbccp32, and legacy_stdio_definitions required
by the latter with current versions of UCRT.
It seems to work OK for others; but being unable to find what's different
on my system, I have this workaround, using run-time loading instead.
Change-Id: Ic4094398f7510bc281dfa96f980f29f12f09d7ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147626
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
cppu::UnoType<sal_uInt8> corresponds to UNO boolean, so its use made the
unsigned values be converted to a true/false in Any; and additionally,
using such a boolean Any, even having a 'true' value, as a parameter to
a double argument would make operator >>=(const Any &, double &) return
false, giving the resulting double equal to 0.
The wrong conversion of UShorts and ULongs to cppu::UnoType<sal_uInt8>
(aka TypeClass_BOOLEAN) was introduced in commit
11f9aa4fcb2ad0a5fada8561c7041e7f25a059fc
Author Andreas Bregas <ab@openoffice.org>
Date Thu May 10 14:22:42 2001 +0000
#79615# sbxToUnoValue(): Choose smallest possible type for numeric values
Treating of unsigned Basic Byte as a signed cppu::UnoType<sal_Int8> (aka
TypeClass_BYTE) was already introduced in
commit c25ec0608a167bcf1d891043f02273761c351701
Author Jens-Heiner Rechtien <hr@openoffice.org>
Date Mon Sep 18 15:18:56 2000 +0000
initial import
Then, in commit 553cf2a834fcca17be6f7712c53e190e90e260eb
Author Andreas Bregas <ab@openoffice.org>
Date Fri Jun 08 14:59:57 2001 +0000
#87927# Map TypeClass_BYTE to SbxINTEGER instead of SbxBYTE because of signed/unsigned problem
an attempt was made to handle obviously this same problem, changing the
corresponding UNO type to TypeClass_SHORT. But it seems that it created
problems when passing arrays of Byte through UNO to COM, where it needed
to convert to a safearray, so this decision was reverted in commit
dd6ba6b64aec20d37a402bee233e742e29285e88
Author Mikhail Voytenko <mav@openoffice.org>
Date Thu Jul 08 21:33:48 2010 +0200
mib17: #162917# let basic byte use one byte, let olebridge convert sequence to safearray correctly
This change tries to avoid the problem that caused the latter revert,
by only treating Bytes as UNO shorts in getUnoTypeForSbxValue, where
scalar Byte values are considered, keeping old handling for arrays.
Change-Id: I805108743376e2fc27dd21a27c31759b76dc0d09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136526
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Moves the custom cleanup logic to overridden SbxMethod::Clear, to simplify
the cleanup code and make sure it restores empty Variant correctly.
Change-Id: I01fa0529acd9ac787ffcda60fd6836ade4afdcb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136108
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...like my local ASan+UBSan build, which now happened to fail once with
> Failed: TestReplacePerformance (t = 60 s)
> Tests passed: 0
> Tests failed: 1
when the machine was under load during a parallelizing `make check`, following
up on 3564b5c6e93b2bf5881b359015efae351dbe8342 "Adapt test to slow builds"
Change-Id: I8f0c8f7e6e145b6d5009f48d2af865ea5caab375
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
First, the integer function result is returned in a 64-bit register (RAX),
and truncation it to sal_Int32 breaks any pointer return value.
Second, using explicit (not vararg) first function double argument would
pass it through XMM0, without also copying it to RCX (which is guaranteed
for varargs).
Ref: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention
Change-Id: I08212c44d8690d6910068b13c16af2ce899c94f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129808
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...like my local ASan+UBSan build, which kept failing with
> Failed: TestReplacePerformance (t = 35 s)
> Tests passed: 0
> Tests failed: 1
when the machine was under load during a parallelizing `make check`
Change-Id: I59c81a61a29df7165f6fad33e3fe3da975f05ed2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129237
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I hope that this performance test is OK. I chose 20 s threshold, as
it works much faster on my system (under 4 s); it shouldn't be much
slower elsewhere; and both the original bug, and the regression that
followed the initial fix, made it execute orders of magnitute slower
(I expect hours on fast systems).
Change-Id: I75ee4c60e562473fe70a203faa94b48c5fbfb4fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
