Inspired by a recent bug report where we were assigning the result
of VclPtr<T>::Create to a raw pointer.
As a consequence, we also need to change various methods that were
returning newly created Window subclasses via raw pointer, to
instead return those via VclPtr
Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b
Reviewed-on: https://gerrit.libreoffice.org/31318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
this is exposed through uno however, so move it into VCLXMenu to continue to
support it doing nothing of great value there
Change-Id: I6888e61cbec85faa2d1fcca8731ab42023e594c6
Deallocate the XTransferable object async using AsyncCallback
(that uses Application::PostUserEvent) which executes the
callback in a thread-safe way on the main thread. This avoids
a deadlock at deallocation so that the XTransferable.
Modify AsyncCallback to not hold the SolarMutexGuard because
Application::PostUserEvent is considered thread-safe.
Document Application::PostUserEvent thread-safety
Change-Id: I4237a1cf380e8be66b3eefc393a58bb4853bf4e1
Reviewed-on: https://gerrit.libreoffice.org/31126
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Look for places where we are accidentally assigning a returned-by-value
VclPtr<T> to a T*, which generally ends up in a use-after-free.
Change-Id: I4f361eaca88820cdb7aa3b8340212db61580fdd9
Reviewed-on: https://gerrit.libreoffice.org/30749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
anywhere anyone wanted to Get[Font|Color] give it the Label
ones instead.
why this is exposed through uno is bewildering, stubbed those
out for the moment
Change-Id: I7a31d027287436be1c075c76a370047efd010bf3
I left a prefix on the names "Map" so that I would not have to re-arrange
each name too much, since I can't start identifiers with digits like "100thMM"
And remove RSC_EXTRAMAPUNIT, which doesn't seem to be doing anything anymore.
Change-Id: I5187824aa87e30caf5357b51b5384b5ab919d224
Reviewed-on: https://gerrit.libreoffice.org/29096
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which was introduced with 3ead3ad52f "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
The issue of 362d4f0cd4 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
some places are marked with "dodgy"- need to check those to see
what is going on, because they are leaving dangling pointers behind
in the Menu class
Change-Id: I41d5c7c0fec2f70ce9e3ffdc48cd03d26c0a869b
Reviewed-on: https://gerrit.libreoffice.org/26516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Low priority idles can fire more or less randomly, and consequently two
consequent runs of LibreOffice differ in the amount of the idles that have
been performed during an operation.
This commit adds a possibility to turn on a 'deterministic mode' where two
subsequent runs of LibreOffice trigger about the same amount of events when
they perform the same set of operations.
Change-Id: I92566ef4eee20e7d604cfd48f01c4df30c77e653
and remove the casting silliness, allowing the removal of
cairo_cairo.?xx
If anything is to go wrong I'd guess it'll be the windows directx stuff.
Change-Id: I3e22c07b9c26ade9b27a245fdd8408de540643f4
anyplace calling GetSystemChildSystemData on a SystemChildWindow is definitely
right
anyplace calling GetWindowSystemData on a Window *might* have intended to call
GetSystemChildSystemData on a Window casted back to an underlying
SystemChildWindow.
Change-Id: I7dcf3a50d0b7ed29bc08cfdb15cc0dcb86be8fa7
Reviewed-on: https://gerrit.libreoffice.org/25158
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
...which (in LIBO_INTERNAL_ONLY) for Clang expands to [[clang::fallthrough]] in
preparation of enabling -Wimplicit-fallthrough. (This is only relevant for
C++11, as neither C nor old C++ has a way to annotate intended fallthroughs.)
Could use BOOST_FALLTHROUGH instead of introducing our own SAL_FALLTHROUGH, but
that would require adding back in dependencies on boost_headers to many
libraries where we carefully removed any remaining Boost dependencies only
recently. (At least make SAL_FALLTHROUGH strictly LIBO_INTERNAL_ONLY, so its
future evolution will not have any impact on the stable URE interface.) C++17
will have a proper [[fallthroug]], eventually removing the need for a macro
altogether.
Change-Id: I342a7610a107db7d7a344ea9cbddfd9714d7e9ca
...which itself only contains a "break" (or nothing at all at the end of the
"switch"), as otherwise Clang -Wimplicit-fallthrough would warn about these.
Change-Id: I25c1cf2ca74dfeba7ca0385ca8f1c1bf30bbf91b
Noel Grandin