most of length in vcl are calculated in 'long'
but array of X position tend to be in sal_Int32.
As a prep work to be able to support 'double'
as the base type of Device Coordinate, harmonize
the use of 'long' for non-float coordinate.
Change-Id: I7cb33301ff6a5e2c62247b36a4e07e168a58a323
This required some changes to the framework:
* Init-/DeInitVCL is no longer done per individual test in BootstrapFixture, but
once per CppunitTest invocation in a new vclbootstrapprotector (similarly to
the exisiting unobootstrapprotector). CppunitTests that need VCL now need to
declare gb_CppunitTest_use_vcl.
* For things to work properly, the UNO component context needs to be disposed
from within DeInitVCL (cf. Desktop's Application::DeInit called from
DeInitVCL). The easiest solution was to introduce an
Application::setDeInitHook (where the hook is called from DeInitVCL)
specifically for vclbootstrapprotector to call.
* PythonTests don't (yet) call DeInitVCL; they still hook into
BootstrapFixture's original test_init functionality (to call InitVCL), and do
not make use of the vclbootstrapprotector.
Change-Id: I4f3a3c75db30b58c1cd49d81c51db14902ed68b2
This test is already disabled on non-Linux, but it fails in case there
is no display to use. For now just disable it in that case.
Change-Id: I29c52e803a1fca5f2bdeeb655c573ad8fef622e8
We didn't have EMF+ rendering testcases so far, let's see if it works
out to render into a bitmap and then just assert pixel position colors
there. It's better than nothing for missing shapes at least.
Change-Id: I2d1c63fef1127f69af7156ed6c99553845f77c9f
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
It's not very efficient, because we generally end up copying it twice -
once into the parameter and again into the destination OUString.
So I create a clang plugin that finds such places and generates a
warning so that we can convert them to pass-by-reference.
Change-Id: I5341a6ea9e3190f4b4c05c42c85595e3dcd83361
rSt >> pPtr[3] >> pPtr[2] >> pPtr[1] >> pPtr[0] results in error:
no match for 'operator>>' in 'rSt >> *(pPtr + 3u)'
Change-Id: I1820bac8c72f7633ab01a17bf5d073b988e1b58c
Reviewed-on: https://gerrit.libreoffice.org/8207
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
First, I updated the clang rewriter to do the conversion.
Then I lightly hand-tweaked the output for the few places where
the rewriter messed up, mostly when dealing with calls on "this".
Change-Id: I40a6a977959cd97415c678eafc8507de8aa3b1a9
Reviewed-on: https://gerrit.libreoffice.org/7879
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
we can use -1 as the failure return code as return value is always checked and
isolated from the rest of the code.
Change-Id: I87a743de82d681a7e4eabc61a576c4e50f1279a8
