Change-Id: I6321a722be6779d839459ed71b793a46e0968567

we may want to use syntax highlighter class from svtools later,
which is not available for l10ntools

Change-Id: I5a06b77cb6935e3ef68015fb608aa26ac7c53fac

Linking of cppunittester (and any other executable that uses
SAL_IMPLEMENT_MAIN or SAL_IMPLEMENT_MAIN_WITH_ARGS) fails otherwise.

Change-Id: I778941ab2069819789f96ab04f364ea61cf4a3cb

Change-Id: Id554c4aba878b329351b2c61e0e90d4515debd6a

Change-Id: Ic602fd4df63e6807f49c256ce7849ae587eeb82d

Change-Id: Ia0c399470b933824ae6fefbb486cf742f72312fd

Change-Id: I33785ba3b9fb100b1ffb0d0ac78894593bf52ee9

Change-Id: I41829e8464fb2fb5e7bbc435f9aa5ed72e7d5cbc

Change-Id: I4028296dd86eef2b8f84cab15eba3c4c15b18c6f

Change-Id: I0373b40ee404c74ca3c2bd479c5f7b18b7495548

Change-Id: I383a631961e2db1e0eb92e78995c9e8c4b232264

For one, assert.h is designed to be includeable multiple times with changing
NDEBUG settings, so it is not robust to include it early in sal/macros.h with
"correct" NDEBUG settings and potentially include it again later.  For another,
there is #ifndef NDEBUG code providing functionality used exclusively within
assert calls, which must be compiled with the same NDEBUG-setting as the
relevant #include <assert.h>.

Change-Id: I7b2f9c85f8e2155051274757c64162ed5a5e9d1b

Change-Id: I7ba421479cd332e059ed9da1c6090e2df420347e

This reverts commit 2dfe34ce:

* sal/saldllapi.h is about something different than sal/types.h (it is rather a
  mistake of cf77e8a0 "sal: add visibility
  symbols" to shortcut the #include of sal/saldllapi.h into sal/types.h instead
  of the headers that actually need it), not every header needs to include
  sal/types.h

* sal/config.h is the header to always include first (not sal/types.h)

Change-Id: I217f2540197ddb682c6c00e529b812b04b327d73

Thank you Markus for your feedback

Change-Id: I10fc6e2be8d648f3be1d2081582c90e27cf3505d

Change-Id: I40c58967aca4f9a808feb8528f2f3ba651bb2a80

Change-Id: I9d651303fb80ef5c81d608e56a87cb9548c13f8f

Should we use vector for m_pListLevels and use iterator then?
Where does the "10" come from?

Change-Id: I2c0d569db48226149645f039ca11633ae2b6c7a2

Change-Id: I64eadd8f34e9d60e9d696fa572dc0001532eab02

Change-Id: Ia6a14d2365fe0a31892517387035e4ebec1f25eb

Change-Id: Id2db7abdec7373082f85fb9d8479427d09cc0a12

Change-Id: I38d62d2c095b87f08d37acfc26df07a4920be4d2

Change-Id: Ic5478199d8ff1cd79dc54e680e8a6c257e7d8325
Reviewed-on: https://gerrit.libreoffice.org/625Reviewed-by: Olivier Hallot <olivier.hallot@alta.org.br>
Tested-by: Olivier Hallot <olivier.hallot@alta.org.br>

Change-Id: I0e49d84b5a7aa47dc315735a8198ba7fdde0b4e7
Reviewed-on: https://gerrit.libreoffice.org/621Reviewed-by: Olivier Hallot <olivier.hallot@alta.org.br>
Tested-by: Olivier Hallot <olivier.hallot@alta.org.br>

and put leading spaces back on merge. It will result in cleaner
strings in .po files, and indentation of Basic code examples
will be kept more easily.

Change-Id: Icdd5cb94069f506ed0b7edf7483ccfd139f296aa

Change-Id: I146e29a68b04ce227fd2b9568fd2bbcd79b45792

Change-Id: I1befdc4c9772c4bf66ee12bf0d2d4aa303903099

aStyles contains rtl::References, so the erase() call may cause "p" to
be deleted, while "p" is then used as a parameter to Broadcast;
avoid this by retaining the rtl::Reference on the stack a bit longer.
Valgrind warning observed in sc_unoapi sc.ScStyleFamilyObj on
libreoffice-3-6 branch, called by ScStyleFamilyObj::removeByName.

Change-Id: I96d6de85b1b182b5ae3f74e92987a7f137537ffb

At least it failed on me once trying to store to its temp file, maybe
the predictable file name was the problem...

Change-Id: I78918ada1615c8337e4c8692d34aa285010bc820

...more to follow (easy hack?)

Change-Id: Icb02626495701a3905c124c7368b98c3258e91b2

Change-Id: Ib7454253df250ddc991aed0dd5cd5b0f90476dd8

Change-Id: I391e08c2712a51fe0adcd3f0c74d779b07c31c76

Change-Id: Ib0cbe1a3347e7231e7908b9bd8135e984e6ef644

* As UCB is only ever initialized with "Local"/"Office", remove this
  configuration vector completely.  The "create" ctor creates an instance
  internally initialized with those "Local"/"Office" keys.  Special (test) code
  can still instantiate an uninitialized one via plain createInstance.  And for
  backwards compatilibity process startup still ensures to create an initialized
  instance early, in case there is still code out there (in extensions) that
  later calls plain createInstance and expects to get the already-initialized
  (single) instance.

* XInitialization is an "implementation detail" of the UniversalContentBroker
  service, do not expose in XUniversalContentBroker.

* ucbhelper/configurationkeys.hxx is no longer needed and is removed.

* ucbhelper/contentbroker.hxx is an empty wrapper and is removed; however, that
  requires ucbhelper::Content constructors to take explicit XComponentContext
  arguments now.

* The only remaining code in ucbhelper/source/client/contentbroker.cxx is
  Android-only InitUCBHelper.  Is that relevant still?

Change-Id: I3f7bddd0456bffbcd13590c66d9011915c760f28

Create a merged XUniversalContentBroker interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.

Change-Id: Id264387bf8af8bf211050e15b8801a1fde368167

Change-Id: Ib351d92d071f6e93ec5eac93c0ab964cef7e7e2f

Change-Id: I4faedd535421eaf1e3e425f4731b3bb8831e7360

The character properties of the field are applied when the next run
begins, so insert an empty run right after the field to fix the issue.

Change-Id: I18d747d99d6604fa331a0e70e6989f9f4975eab2