all most all of the places in the basic basctl modules this bug fixed
Change-Id: I1a4a03e207c1b520449c31a05265585120da07f6
Reviewed-on: https://gerrit.libreoffice.org/27662
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
since...
commit ba81e5c6bd420b41a84ade6ccd774011a8089f7f
Date: Thu May 28 21:35:43 2015 +0100
tdf#91702 - fix stack-based MessBox allocation.
There is no special ScopedVclPtr<X>::Create or
ScopedVclPtrInstance<X>::Create just
VclPtr<X>::Create and a raw VclPtr<X>::Create()->foo
doesn't call dispose on the owned X
Change-Id: Ifacc8d5e742820701307c3c37b9b86487667d84f
Based on suggestion from Aron Budea.
And do something similar to most other places keeping vectors
of weak references where the code looks like it will hold more than
a few entries.
Measurements:
the 26 page file file takes
51s without my path
15s with this patch
the 69 page file file takes
5m28 without my path
51s with this patch
the 84 page file file takes
8m28 without my path
58s with this patch
Change-Id: I8da94c525fc73ebd969e0343c6f074be4f0063b1
Reviewed-on: https://gerrit.libreoffice.org/27093
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
... implementing signed years with year 0 gap.
Date(31,12,-1) last day BCE
Date(1,1,1) first day CE
New class Date member functions:
* AddYears(sal_Int16) to be used instead of
aDate.SetYear(aDate.GetYear()+sal_Int16) to handle year 0 gap.
* convenience GetNextYear() to be used insted of GetYear()+1
* convenience GetPrevYear() to be used insted of GetYear()-1
* AddMonths(sal_Int32)
* operator=(const css::util::Date&)
New class DateTime member functions:
* operator=(const css::util::DateTime&)
Made some conversion ctors explicit, specifically Date(sal_Int32)
Adapted hopefully all places that used a sal_uInt16 year to use
sal_Int16 where appropriate.
Eliminated some quirks in date handling found on the fly.
Added era handling to i18npool icu calendar setting interface, which
missing was responsible for 0001-01-01 entered in Calc being set as
-0001-01-01, hence subtracting one day resulted in -0002-12-31.
Change-Id: I77b39fba9599ebd5067d7864f6c9ebe01f6f578f
Reviewed-on: https://gerrit.libreoffice.org/27049
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
, 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>
from a range address
trying to make all SbxVariables reference count their parents
is ludiciously hard, so just reference count this one known
crashing case
Change-Id: Ie1fa6624e8184146dd00d766cdbacef674153ef6
Reviewed-on: https://gerrit.libreoffice.org/26272
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
uno::Reference is only allowed to used with classes that have a
::static_type member.
So convert all those places to rtl::Reference.
Maybe we need some LIBO_INTERNAL_ONLY constructors on rtl::Reference and
uno::Reference to make this a little smoother?
Change-Id: Icdcb35d71ca40a87b1dc474096776412adbfc7e3
Reviewed-on: https://gerrit.libreoffice.org/25516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
...now that sal_Unicode no longer clashes with sal_uInt16 on any platform (in
LIBO_INTERNAL_ONLY code), after e16fa715c43dcdf836ce8c400b6d54eae87b627d "Handle
wchar_t as native C++11 type on windows"
Change-Id: Id423dd6235bf14823fa5611b804c0974edbe64b3
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>
its a SfxLibrary which is not a XLibraryContainer
(a SfxLibraryContainer is however)
I think the issue is simply an empty name making code go down the container
rather than library route.
Change-Id: Ib0245d402fe375ac26ab9f2b14fe708b2a34a7a7
and fix the operator< implementations in some of the other
plugins too.
Change-Id: Ie5631e0cdc8d2a994ad2af2533cdb558a6cfc035
Reviewed-on: https://gerrit.libreoffice.org/25057
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
