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>
#If Vba7
Declare PtrSafe Function xx
#Else
Declare Function xx
#End if
Change-Id: I807efb9fa68b5ac50f2bd59ba7cfa45c499af189
Reviewed-on: https://gerrit.libreoffice.org/34522
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
This reverts commit 93a8ebac2d6eb124bf57223069765af08fcd5c85, now that
fce604c8ae11b462113305aba080d77f8193cfea "[API CHANGE] return unsigned 64-bit
value from GetSystemTicks in basic code" is in.
Introduced with 060c2b9b1b0d3c9cf27f1b289a620cfa82b5b060 "QA Basic: split tests
of methods in different files", but GetSystemTicks appears to routinely return
negative values.
Change-Id: Ibccdf753aea581e05e9d4e1bf551ae72dc70c959
Following resolution of "Missing TAN method" [1]
as discussed on dev list [2]
a large majority of methods are now tested
with (almost) one method per file
Missing methods:
- colors failed: RED, GREEN, BLUE
- file methods: DIR, CHDRIVE, EOF,...
- financial methods calling Calc functions: IPmt, IRR,...
- not totaly implemented methods (?): ROUND, WAITUNTIL...
[1] https://bugs.documentfoundation.org/show_bug.cgi?id=102872
[2] http://nabble.documentfoundation.org/QA-test-for-BASIC-functions-tt4202257.html
Change-Id: I2b2824b5b18a2cfbbee2bbc5369e9e2b9e5c930b
Reviewed-on: https://gerrit.libreoffice.org/32519
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
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>
Add test if several methods still works
Change-Id: I8d26e5e3555dbbc0f07152138e1bc0cd65d90998
Reviewed-on: https://gerrit.libreoffice.org/30166
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
Reviewed-by: Laurent BP <laurent.balland-poirier@laposte.net>
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
, ScriptDocument
, PropBrw
, VBATest
, SbUnoClass
, SbModule
, and SbiSymPool
It is more readable and more efficient as a bonus.
See: https://goo.gl/jsVAwy:
Change-Id: I73926989345193b133e538d5aeca36f12723162c
Reviewed-on: https://gerrit.libreoffice.org/26853
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
And fix leak in BasicManagerImpl where it would never have freed
the streams.
Change-Id: I1e99c2c6a70a8cac27dd5c86a7042efc3de7a578
Reviewed-on: https://gerrit.libreoffice.org/26632
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
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>
Unit test for https://gerrit.libreoffice.org/21021/
Add unit test for Engineering format
Add unit test for optional sign in exponent
Change-Id: I958ccdcc68a4e496cbd4bdc74d0650c133f3a3f7
Reviewed-on: https://gerrit.libreoffice.org/21824
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.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>
