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/22924
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
regression, likely from 2660d24a07:
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/24020
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.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/23921
Tested-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
The spec says in theory a % suffix could be also supported, but let's
wait till that is seen in a real-world document.
Change-Id: Ie026915e38dcb03c99085a1740075364b00e1c8d
m_nRT2 and m_nWinBits fields are not in use anymore, at least as far
back as 2013, when the heading files were moved around
Change-Id: Ie3299a5999976450803332aeab72d5c0e68227e2
Reviewed-on: https://gerrit.libreoffice.org/23960
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Sequence.h(xx), Any.h(xx) and Type.h(xx)
and remove unused using-declarations from these files.
Add a few missing includes provided by them.
Change-Id: I6b91b6d1fdf9d0496dd546c0aab9bdcc6831a5d4
Reviewed-on: https://gerrit.libreoffice.org/23805
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
The sfx2 impl. of XStorable::isReadonly isn't really helpful
for files w/o write permissions that were switched to edit
mode, as it returns the state of the UI. So instead let's just
rely on the state of the .uno:Save slot.
Change-Id: I3b033be3c9424a4479e9224f02d186960b540d21
Save as/to remote don't work there. Still would be
nice to have the modified state icon change there too,
but that's for a future investigation.
Change-Id: Id119a40c39f9c69738b1e61e23ffe3424276229e
What a mess. Ideally, Frame would use its own rBHelper.rMutex, not SolarMutex.
But much of the framework code it calls into uses SolarMutex, too, making it
difficult to change that without running into the risk of deadlock. And then,
some member variables are cleared early in Frame::disposing, while others are
only cleared en bloc at the end. Be conservative and keep it that way (as other
Frame functions recursively called from within Frame::disposing could observe
the difference and rely on the current behavior), even if that means creating
lots of small, independent locked regions within Frame::disposing (which can be
detrimental to both performance and correctness).
Change-Id: I28f9a379ce03ed661e96c7deb8eb73cb58fb2cf7
