Rename test_tdf149714.cxx to test_tdf149714_bits_per_pixel.cxx
to provide a human-readable hint about the purpose of the test.
Also update CppunitTest_basic_macros.mk accordingly.
Change-Id: Iba5db7ebed9bc1aeafe1b365243e1e0ca8216070
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199692
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
- 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>
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>
In the old algorithm, some special unicode characters lead to a
malfunction of basic's replace function. For instance, replacing a
German ß to uppercase in the insensitive case will lead to SS, breaking
the replace positions.
Change-Id: I4e6f6e5fba3d560b8cfd0786fa2439ed5174a928
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118760
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
"As New" variables use lazy instantiation, but that should not re-apply each
time one re-enters the module. If the object is still there, don't replace it.
Change-Id: Ic568a56b93db9bc9139d434d97a4a4deb05840df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112018
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The original
$(if $(filter 140,$(VCVER)),legacy_stdio_definitions)
had been added with d2a44e6270 "tdf#99696 fix
build error for 64bit Windows in unit tests using ADODB" at a time when
configure.ac supported VCVER=120 (i.e., VS 2013) and VCVER=140 (i.e., VS 2015).
It was presumably meant to express the condition
$(VCVER) >= 140
which is always true by now (where our baseline is already at VCVER=150, i.e.,
VS 2017).
Change-Id: I1cd48604d102c32e1d829395b65a00539f318b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89686
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
New compiler changes quite some stuff:
* Compiler detection done based on different registry key
* .NET SDK detection done based on different registry key
* Msbuild installation directory changed
* Merge modules installation directory changed
* SDK number in registry doesn't match the directory name:
(registry key: 10.0.14393, directory name: 10.0.14393.0)
* Compiler, include and library location directories changed
* Architecture specific directory changed: x64 instead of amd64
* Compiler own include directory must be added with -I option
* To force usage of SDK 10 (8.1 is selected per default) new
switch WindowsTargetPlatformVersion is passed to msbuild, to
avoid patching VC project files with this line:
<WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion>
Known issues:
* Firebird is broken: http://paste.openstack.org/show/594333
Change-Id: I148d7932aff43bbbd07bd493504df974726234c2
Reviewed-on: https://gerrit.libreoffice.org/31279
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
This patch fixes the problem that the build for x64 fails in basic module
on 64bit Windows installed 32bit Excel Application.
New code checks the existance of ODBC driver for excel insted of the
existance of Excel application(at this time the bitness of ODBC driver for
excel would match that of building LibreOffice).
What we need is probably not Excel Application but ODBC drivers for proper
bitness.
Change-Id: I62285eb2351f2022754fc34cb2d54db1bd9e8142
Reviewed-on: https://gerrit.libreoffice.org/25301
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
madhura