Added vcl/settings.hxx to all cxx files which require it.
This helps to speed up compilation after changes to the settings.
Conflicts:
sc/source/ui/dbgui/pvlaydlg.cxx
Change-Id: I211a0735c47f72d6879f6f15339355abfe0e3cf4
Reviewed-on: https://gerrit.libreoffice.org/7933
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@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>
.. to more explicit SvStream::Write* calls
This was done using another run of the clang rewriter, and then
a lot of hand tweaking to fix all the places where the rewriter
did not play nice with various macros.
Change-Id: I7bcab93851c8dfb59cde6bc76290c6484d88fb18
Reviewed-on: https://gerrit.libreoffice.org/7494
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
This is the actual re-write.
Use a clang rewriter to rewrite SvStream::operator<< to methods
like WriteuInt32.
Note that the rewriter is not perfect, and I hand-tweaked the output.
In particular, I had to adjust places doing things like
(*this) << 1;
Change-Id: I5923eda3f4ebaa8b452b6ef109e726e116235a2a
Reviewed-on: https://gerrit.libreoffice.org/7342
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Utility functions to convert between Basic Date type
and the representations of Date and Time in UNO, namely:
- com.sun.star.util.Date
- com.sun.star.util.Time
- com.sun.star.util.DateTime
Name of new functions:
- CDateToUnoDate
- CDateFromUnoDate
- CDateToUnoTime
- CDateFromUnoTime
- CDateToUnoDateTime
- CDateFromUnoDateTime
Change-Id: I2b971df20df1c0351d071023e042169b548894f1
Reviewed-on: https://gerrit.libreoffice.org/5897
Reviewed-by: Noel Power <noel.power@suse.com>
Tested-by: Noel Power <noel.power@suse.com>
This reverts commit 6c61b20a8d. As discussed at
<http://lists.freedesktop.org/archives/libreoffice/2013-May/052449.html> "Re:
fdo#46808, Convert awt::UnoControlDialogModel to new style problem" why the odd
change in 2e2a4827ce "scripting: get
CreateUnoDialog() work again" appears to fix things again:
The problem is that the implementation of the css.awt.UnoControlDialogModel
involves UNO aggregation
(IMPL_CREATE_INSTANCE_WITH_GEOMETRY(UnoControlDialogModel) in
toolkit/soruce/helper/registerservices.cxx creating a
OGeometryControlModel<UnoControlDialogModel> instance that aggregates a
UnoControlDialogModel instance). That means that queryInterface can return a
reference to something that is technically a different object, and that's
what's happening here, and explains why calling setPropertyValue in two
different ways on what logically appears to be a single object can end up
calling two different implementations (of two different physical objects).
(UNO aggregation is known to be broken and should not be used. Nevertheless,
there's still code that does---code that is a horrible mess and hard to clean
up.)
That all this worked as intended in the past is just sheer luck, but any
way of substantially touching it is asking for trouble. I'm going to
revert 6c61b20a8d again.
I wasn't able to revert without also reverting
be50ad28f5 "fdo#46808, Convert
awt::XUnoControlDialog to new style," as the two were tightly dependant. Also
reverts all the follow-up fixes cb4b6dde8f
"-Werror,-Wuninitialized" (sans the const-ness fix in
UpdateHandler::insertControlModel), 697a007c61
"Fix exception specifications," 2ce6828bbb "fix
awt::UnoControlModelDialog crash," and 2e2a4827ce
"scripting: get CreateUnoDialog() work again."
Conflicts:
basctl/source/dlged/dlged.cxx
filter/source/t602/t602filter.cxx
xmlscript/test/imexp.cxx
Change-Id: I5d133468062f3ca36300db52fbd699be1ac72998
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Also, avoid global static data in sb lib, so that gengal.bin now also works well
on Mac OS X, cf. 12fa9ece66 "Avoid global static
data."
Change-Id: I23f2a7abc0c06a752ded1c1c64619b3aab009190
...so that e.g.,
DateAdd("x", 1, "1/31/2004")
(where "x" is not in the list of valid values for the Add parameter, "yyyy",
"q", "m", etc.) leads to a Basic runtime error rather than going into a
seemingly endless while(nNewMonth>nTargetMonth) loop at the end of
RTLFUNC(DateAdd) (basic/source/runtime/methods.cxx).
Change-Id: I15c3bdb62723ffddf36ff2396ffb294369d93ff8
parsing 1000s of line of code is hard enough without having to fight
with weird indentation and irregular formatting.
So as the review progress, in order to follow the code, cosmetic changes
were made...
In order to minimize the task of the reviewers and allow them to
concentrate on what matter, an effort is made to collect these
cosmetic changes into this separate commit.
Change-Id: I3c9b04a0150d0d0a048c2e976fe24de4f2b6b98a
Did not need to create a new interface, because XCalendar3
already covers the whole service interface.
Change-Id: Iaf094014c16e872d2003ca6e8e7588abd081d882
The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
