Change-Id: I443d7d82de72841b1ac1f2ed026c647e3f1957fc

Change-Id: I5e6938385ce870579982f21ad824081f4cc1ef60

Change-Id: I4a4bf1aa1d6afe819c22288474be302fe95740d1

Change-Id: Iab728d51c24ccbedad5fa181850a673129d489ae

Change-Id: I6c8565653ece37251a98103f71408ace2a0946a8

Change-Id: Ie832e82ca3767114457780581444f6fc8aa9fdd2

Change-Id: I8adf61a63e6e6102a44cd18652192fde0a89287a

Change-Id: I1f1adf0790490a600ec164793ab7ee8ed0adc29e

Change-Id: I1058455f4d5f3bfbe25b196181bd57043aff1c40

Change-Id: Ic44d1c751319897c55fdd03c912cd670624f928f

Change-Id: I1b50fadd64df0a18339410068696a836850e9248

...introduced with 9f34fde7 "libxmlsec" but
always unconditionally defined.  Fix some indentation.

Change-Id: Ib46d4d7153d84975e9bcd8351779634f8d43240c

Change-Id: I0a8dc9591c00188d0a31feb784d14ec53f389f27

Change-Id: I5390fe81a7b35d62a27cd1ec6fb00ea012e70dd9

Change-Id: I8b8d0322e62a64379eb72ca648c06b092c363f6a

Change-Id: Id89697b602508446be0c9578b49532de6c22be9f

Change-Id: I0ed8754bb06328b61a41079a4f446d8dd2b61bb7

Change-Id: If64f146fd9c6417ed16d459cef39b3a2d47bfb4d

... by asserting that the current thread is the owner of the
SalYieldMutex.  Anything else would be a bug anyway.

Change-Id: I564c184ae21b99a096f67edbc729b3f2b0e307de

The ordering between clearing mnThreadId and OpenGLContext shouldn't
matter since it was already inconsistent.

Change-Id: I0b7b6457547e9e38527de58ba062fd7092178056

... so the next time something overflows the main thread's message queue
it's easier to debug.

Change-Id: I90a35e46f3b2cab190c7da5e53024ec549159ac6

Change-Id: I3ca3f7732583111c8f49cc6fc71ba9fcada08f96
Reviewed-on: https://gerrit.libreoffice.org/23990Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: Ib941321d43a9a04d57f3c7c4a55528927fed5036
Reviewed-on: https://gerrit.libreoffice.org/24009Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Xisco Faulí <anistenis@gmail.com>

I removed all the OSL_DEBUG_LEVEL > 1 conditionals by SAL_INFOs
or OSL_DEBUG_LEVEL > 0

Change-Id: I261644a179e763612204bbb0e54a869fa1a62298
Reviewed-on: https://gerrit.libreoffice.org/23035Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

I removed OSL_DEBUG_LEVEL > 1 conditionals by SAL_INFO(..)s
or OSL_DEBUG_LEVEL > 0 and made sure that it doesn't break the
build

Change-Id: I3eccdd769ff32e57e12209706e5fbbdd9638de54
Reviewed-on: https://gerrit.libreoffice.org/23068Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

I replaced OSL_DEBUG_LEVEL > 1 to OSL_DEBUG_LEVEL > 0 conditionals
as suggested in easyhack. I didn't convert those fprintf statements
because they were required for debug output formatting according to me

Change-Id: I54d5b0873f527fd04d736eeb01d18f73eb9be74f
Reviewed-on: https://gerrit.libreoffice.org/23069Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

I disentangled my previous patch to make one patch per module. I also
modified the patch according to new directions given by Sweet5hark

Change-Id: Id690f7c1e87230e4d10e1c9fe472f35d1d1caa8b
Reviewed-on: https://gerrit.libreoffice.org/22924Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

regression, likely from 2660d24a:

1/ Since that change mxAccessible in ScCsvGrid holds a rtl::Reference on
a ScAccessibleCsvGrid
2/ Which in turn holds a VclPtr<> (aka a rtl::Reference with lipstick)
on the ScCsvControl

These are a circular references, making both of them live forever and
leak past the point where on LibreOffice close all of Vcl is long gone,
when these are dtored. Clearing mxAccessible on disposing should help.

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

Change-Id: Ie48eb08edd1335661d1ef57ae652713143951317

Change-Id: I80987ea1bfac7478574de46ee30fc58fcc17eb68

Change-Id: Ic8d319dac1d18f548d47ac84e489c04412a38d1a

Change-Id: Id55410931305a9695a001977a5227b430a984e99

Change-Id: I6818f6c9593bfe7105cc194fcf6f69131046e4f3

Change-Id: I9cec61867b4e6e8abde7749047974c6de87b9669

Change-Id: I93a09bf8e475ec1aa2ebf7754c7048c81696922b

Change-Id: Id33dce9714737dd28ce48c22f966c9747c2db20b

Change-Id: I1f61be80ac1ebe42668580b09a261e7e3af1a403

Change-Id: I387417bf8fdfa85379b6d8eaa32738d0ed7ab519
Reviewed-on: https://gerrit.libreoffice.org/23900Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>

Currently the Windows-specific method ImplSalYieldMutexAcquireWithWait()
uses a messaging mechanism to learn about the SolarMutex being free again.
This is not reliable when the MessageQueue overflows (MS allows 10000
messages per queue). It is more safe to use MsgWaitForMultipleObjects.
This also allows to not only wait for the SolarMutex to be freed, but
also to detect when SendMessage() is used which needs to lead to a
reschedule to not block current Window handling.

Change-Id: Id317dda62aaa1fe7677d8d28929e6936e5a22705
Reviewed-on: https://gerrit.libreoffice.org/23921Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>

In case an image had text, then ShapeExport::WriteGraphicObjectShapePart()
wanted to write "only the text", but PowerPointShapeExport::WriteTextShape()
had no idea how to write an image, so at the end nothing was exported.

Change-Id: I6c1ad0b41d4c5dc260b952322fb8a59e7f175603