(+ label the button)

Change-Id: Icc6a0c5e3e715bcfe1392496bef2514fd1bdb62b

they were growing a bit out of control

Change-Id: I80441179b4d4aacc57c469fc8f3a3937866ceae8

Change-Id: I0e70459e331995388b36c77c351bff89ece004a6

Change-Id: I83235f79d30e5f573fee95a525b4cfe1211a24b7

Change-Id: Iea9984af3f08ed214815b9477019695f2339a7f3

for the moment don't crash anyway, maybe we can rearrange matters
to make this possible.

Change-Id: I2dc9831e5b026004b2f7603e618330154dbd6d1b

This fix is a SCCOL variant of:

commit c66d1b9fcc2244b4fd8940f17ebf4e772f09c84e
Author: Kohei Yoshida <kyoshida@novell.com>
Date:   Thu May 5 00:23:25 2011 -0400

    fdo#36406: Let's not use invalidated iterators.

    std::set::erase(iterator) call invalidates the iterator of the erased
    element.  We better not use it after the erase() call.  Since the number
    of manual breaks should not be high enough to cause a performance
    bottleneck under normal usage, a safer linear copy should just be fine.

    Now, I'm not sure if this indeed is the cause of the erroneous amount
    of manual breaks in the test document, but I didn't see any other likely
    spot.

Change-Id: I0c2e8f738949776aa7f8ea5528e2c0eeb9351c16
Reviewed-on: https://gerrit.libreoffice.org/16063Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Change-Id: I19e96b882a5cc8991035a8275aebd4ff586bf9f3

Change-Id: I5deac9924b99ac1b3e1440623364004b0b44aaf5

Change-Id: Ibecee87ffe3ec6990e36952488668b790a8e54eb
Reviewed-on: https://gerrit.libreoffice.org/16076Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Joren De Cuyper <jorendc@libreoffice.org>

Change-Id: I9a78a75b3d72586b1702ed6fa63bb0b62ce6cd72

Change-Id: I665d2944f5d24b4ec5015274c1b95b106a028291
Reviewed-on: https://gerrit.libreoffice.org/16072Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

This reverts commit 217dbf61, the test should
work now reliably after the preceeding "Finalizers must not access UNO objects"
commit.

If the object being finalized (A) has the last reference to the UNO object (B),
and B is actually a proxy for a remote UNO object, then A and B become eligible
for finalization in parallel, and the finalizer of B may already have run when
the finalizer for A runs.  That means that B may already have been removed from
the remote bridge, causing an "unknown OID" error from the remote end when the
finalizer of A now tries to make a call on B.

(We try to assert that close() has actually been called before finalize() calls
delete(), but the corresponding exception may be silently swallowed by the JVM
finalization machinery.)

This caused spurious "URP: queryInterface request message with unknown OID
received" failures during JunitTest_dbaccess_unoapi.

Change-Id: Ia47c3ef2c22a6adc75b1b8271eb4b3140accebe7

Change-Id: If168a3be2630170636c333e177c5db0d40092cbe

Change-Id: Ic628e4eccab59dce5d6d5e77656cac1f0006a491

Change-Id: I0c97e489150cd65d1ab1dbff4ee9f1699f89ac2e

Change-Id: I2f44e780c7250cdbf40fde8779beb81f29498f8b
Reviewed-on: https://gerrit.libreoffice.org/16071Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: Id538ee368de6cd63f08618e6284bca97e20bf7a3

Change-Id: I21e253ed9dccdab84be4838b5beee9385467ed37
Reviewed-on: https://gerrit.libreoffice.org/16068Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

use begin() and end() when calling std::copy on an uno::Sequence

Inspired by commit b34b648f
"uno::Sequence provides now begin and end"

Change-Id: I08e8c3fd6144e77b95a26f85bc0daf6a9edeeb0b
Reviewed-on: https://gerrit.libreoffice.org/16057Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I03387e8e90891b3477c9c15200acc127262170bc
Reviewed-on: https://gerrit.libreoffice.org/16070Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I4d6ed976f4df63c7c51dd110b45787f2396518e4
Reviewed-on: https://gerrit.libreoffice.org/16069Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I9b0bbf6273aa18ae918d1d69af5dcc7652181f5c

Change-Id: I4fb8f2c9e2080e3aa542d2ccf838e6784baa8429

Change-Id: Ifa401dd0d2d1bef8c0ae2987d2aee86100b59816

Change-Id: Id7e444bc896ae5d52e5a0bd1b471679c4945afa4

and drop unused NONZERO_WINDING_NUMBER value

Change-Id: If2a8f01934796eaf9a343113387b775fd169ccb9

Change-Id: I6eb213d6dcf387936967271fba9e2de3879ef479

Change-Id: Ie4a7705cc3d042d08178e562a2c2ffaf0be3810f

Change-Id: Idf14f7d344be6c690cdd721cd5f7eb7c328b590c

Change-Id: I3fb71868a9f8f56c76353f3a2d84fdb078c8f8fb

overwriting the original one, and when the temp doc goes away then its drawing
layer goes away autoamtically settings the secondary pools of the other pools
it is a secondary of back to 0

(see also tdf#87245)

Change-Id: Ie6dd8d615f81cf4d4776eaeac1cc2507b2abaa37

As agreed in the Design team meeting today.

Change-Id: I660462fb7b56eb3c8f883f8540cf88801e48165c

And call it from the SwDoc dtor, so that embedded data source
definitions registered on opening are deregistered on close.

Change-Id: I40309389d44dcbc225f6f2ef98bb20579e12d650

The problem is that SwDBData just describes the current data source,
and when changing that, the embedded name doesn't change, so they should
be separate.

Change-Id: I2dd7e0a97b9f7d6a3a74a5752467515a0a09171a

Change-Id: Iadf157f3d2673047e2d81c74847b16d12478ca65

Change-Id: I782e93e6106b3940e7e83c615072beebca1c0965

Change-Id: I1d6fc43447c3c98e21d1d0752aa621c9ab2a92a7

Change-Id: Ie84924ee77805ce4b4f6d5a7e77213ce2d51877f