... making its value CRLF on Windows and LF on others.
A winding road of regressions passed through it;
first b680e352546dc614f3b30bbe212e6b415a6a6bf4,
then 7beeced463648fc67defea2ad48d58dd42f0ca1e.
Change-Id: I9e4da4a17436949b4fea35481b8355b4321cb268
Reviewed-on: https://gerrit.libreoffice.org/37500
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
On Windows x64 there are two ODBCs - one for each bitness.
A 64-bit build gets 64-bit ODBC, and there is no provider named
"Microsoft Excel Driver (*.xls)", no normally the test is simply
skipped. But if MS Excel is installed, then it installs provider
"Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)", that was
detected by previous code, but not used inside the VBAs. So, VBAs
tried to use "Microsoft Excel Driver (*.xls)" unavailable to them.
This patch allows using Excel's provider as well, thus allowing
developer to test against 64-bit-specific regressions.
However, the last test uses Microsoft.Jet.OLEDB.4.0 provider,
that is unavailable on Win64. There are substitutions -
Microsoft.ACE.OLEDB.12.0 and Microsoft.ACE.OLEDB.15.0,
but there is no easy way to test if they are installed. Thus,
that test is disabled on Win64 for now.
Also, possible buffer overflow fixed, when byte count was passed
to SQLGetInstalledDriversW instead of char count.
Change-Id: Ib5c55251f0e92b3078a46aee173b5061439445ae
Reviewed-on: https://gerrit.libreoffice.org/32019
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
It fails when Excel is installed, for some reason:
Basic error:
Type: com.sun.star.uno.RuntimeException
Message: [automation bridge] unexpected exception in IUnknownWrapper_Impl::invoke ! Message :
[automation bridge]: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
macro result for ole_ObjAssignNoDflt.vb
macro returned:
C:/cygwin64/home/Tor/lo/64bit-debug/basic/qa/cppunit/test_vba.cxx:155:`anonymous namespace'::VBATest::testMiscOLEStuff
assertion failed
- Expression: pReturn->GetOUString() == "OK"
- Result not as expected
Note that this test returns early if Excel is not installed, so it is
not run effectively performed anyway even in 32-bit builds on most
(any?) Jenkins and tinderbox machines.
Change-Id: I0a0b6f27219dec116369fae1bb7c95b3e9597e77
Conditional statements are using SvRef::Is() method.
Changed static_cast<T*>(svRef<T>) occurances to svRef.get().
Added operator == and != to SvRef.
SbxObject::Execute is using SbxVariableRef internally.
SbxObject::FindQualified is using SbxVariableRef internally.
Change-Id: I45b553e35d8fca9bf71163e6eefc60802a066395
Reviewed-on: https://gerrit.libreoffice.org/29621
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which was introduced with 3ead3ad52f9bb2f9d1d6cf8dfc73a0a25e6778ed "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c390154619c385414bdbe6f6e461173
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
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>
(as some tests derive from the latter only for the Directories part, not for the
setUp/tearDown overrides: those tests will be cleaned up next)
Change-Id: Ib6b78eea868b8bc21d4cc6e8fd9e1d025deca05f
Reviewed-on: https://gerrit.libreoffice.org/23078
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
using an idea from dtardon:
<dtardon> noelgrandin, hi. could you try to run the unusedmethods clang
plugin with "make build-nocheck"? that would catch functions that are
only used in tests. e.g., i just removed the whole o3tl::range class,
which has not been used in many years, but htere was a test for it...
<noelgrandin> dtardon, interesting idea! Sure, I can do that.
Change-Id: I5653953a426a2186a1e43017212d87ffce520387
Reviewed-on: https://gerrit.libreoffice.org/22041
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
