Qt plugin automatically orders buttons for each platform based on
the button's role, which we derive from the Gtk .ui file's
action-widget response code. But to do that conversion from response
code to Qt button role, we need a standard response.
Without a standard response, the button has no role, and gets ordered
to the right of OK/Cancel buttons on Mac. With the correct role, it
is correctly placed far-left along with the Help button.
Change-Id: I16d3126d4999649e7aa6e72ec5e7b1a25f48c2a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210223
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
Switch the weld::Entry and weld::TextView handlers
that are called when the text changes due to user
interaction to pass a weld::TextWidget& param
instead of a weld::Entry& and weld::TextView&
one respectively.
Adjust related methods across the code base accordingly.
This unifies the behavior for both of these
weld::TextWidget subclasses and prepares for
deduplicating the logic and moving it to the
common base class in an upcoming commit.
That will also ensure they stay in sync.
(Change also motivated by the fact that their behavior was
differing before
Change-Id: I03d2a13cd84d53d806eb9e363f49c4b6be28d938
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 9 13:08:58 2026 +0200
tdf#130857 weld: Don't signal about programmatic TextView text change
.)
Change-Id: I5572fc88caf577fae9a23a39f1ec4f2179935a99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses,
as well as a few helpers.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when anything in weld.hxx
changes.
Move the weld::toId and weld::fromId helpers from
weld.hxx to weldutils.hxx, in preparation of getting
rid of weld.hxx altogether in an upcomcing commit.
Change-Id: I408fe20a74ff104cbfe07bde3105317a1922ff61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This makes it easier to keep an overview and reduces
what needs to be recompiled if the class changes in
the future.
Change-Id: Ie8d0aad9bca3e990f78d4ffc006a04b0a8086fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205935
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This makes it easier to keep an overview and reduces
what needs to be recompiled if the class changes in
the future.
Change-Id: If29ec68d2d28dfaf1b11d46c7efc72e128857ccd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205934
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This makes it easier to keep an overview and reduces
what needs to be recompiled if the class changes in
the future.
Change-Id: I16f988657fb183c9701cd14fd953fae6026e5bd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205931
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This makes it easier to keep an overview and reduces
what needs to be recompiled if the class changes in
the future.
Change-Id: I76ff76609646a22f81086e2d28dc53ef322dc64f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205929
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Add missing includes/forward declarations in places
previously depending on transitive includes that
are now dropped.
Change-Id: I3215b358e0fa45ffce08756218c386e1a4d7ebc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205928
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I34876c5bef75e30e758029b0fe5afeecc92d509d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205903
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header and
source file, in order to make it easier to keep an overview
and to avoid having to recompile ~all UI code when the class
is modified.
Change-Id: I91bae842e5b18a83db45de12150c21f75e537fb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205900
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Adjust includes in files that were implicitly depending
on transitive includes that are no longer present because
the more specific include/weld/Container.hxx is included
further down now instead of include/weld/weld.hxx.
Change-Id: I04e6bb72ce446b746dfdf88b45c7df9d0ccda473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205899
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ide86f35543468a88288a068cc9f89eaf381ac52f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205763
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ia7bc570fcd463d9adcbcdad070250cec5bc3b949
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205488
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ibe76e4c871f364904a2ad65921d37ec0380094ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205487
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: If7cb4403f1861c465f44a1cae4065b0bf8dfad48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205323
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This was accidently (and automatically) dropped when
the .ui file was resaved in
commit 2dbed928c7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Feb 25 00:18:15 2026 +0100
spropctrlr: Resave multiline.ui with glade 3.40
and resulted in the dropdown arrow being shown twice
with the gtk3 vcl plugin as described in tdf#171653.
Restore the accidently dropped property again.
Change-Id: Ic0344137b69574bc8e84b2e61975ba2d2e21a57d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203413
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the param for the signal and handlers used when
the selection in a weld::TreeView changes from weld::TreeView&
to the base class, weld::ItemView&.
This is in preparation of moving the logic to the weld::ItemView
base class in an upcoming commit.
Handler implementations that require a weld::TreeView
instance can use the one that the signal is connected
to, e.g. use the class member directly inside of the
implementation instead of using the param (as is done
in most of the places anyway).
Change-Id: I0bbf8fe1dbd95906a5224155d48d832bcd144532
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203366
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Rename methods and field related to signalling activation
of a weld::TreeView row to use the same names as the equivalent
ones for signalling activation of an entry in weld::IconView:
* weld::TreeView::m_aRowActivatedHdl -> weld::TreeView::m_aItemActivatedHdl
* weld::TreeView::signal_row_activated -> weld::TreeView::signal_item_activated
* weld::TreeView::connect_row_activated -> weld::TreeView::connect_item_activated
This is in preparation of deduplicating the weld::TreeView
and weld::IconView implementations for these by moving them
to the common weld::ItemView base class in an upcoming commit.
Change-Id: I4ca4dec1295c57cea574b68fd41b89c12144c4f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203350
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is basically the weld::TreeView version of earlier
commit
Change-Id: I8ca62ac32108f01e2055d5ef9301de22eb5b1931
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Apr 8 12:35:25 2026 +0200
weld: Pass activated item in IconView::signal_item_activated
applying an equivalent change for weld::IconView instead
of weld::TreeView. See that commit for more details/background.
For weld::TreeView, the weld::TreeIter refers to
a full row (and columns are handled separately
by a column index in the weld::TreeView API).
As for the above commit:
Initially, leave the logic of the existing signal handlers/callbackes
(in dialog implementations) unchanged. At least some of them
will be simplified in upcoming commits to use the
newly passed weld::TreeIter param directly instead of
determining the current/activated row a different
way.
Change-Id: Ie6a962702d4f7f069b2f7b77a22a78722b2a6408
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203331
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use OContentTableSelection::m_xSelectTable directly instead of
the weld::TreeView& param passed to the handler.
That is the weld::TreeView that the handler is connected to.
This also prepares for adjusting weld::TreeView::m_aRowActivatedHdl
to pass the weld::TreeIter of the activated entry instead of just the
weld::TreeView itself.
Change-Id: I3747edbacd508c82c56974dfa40beb775a3d3052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203303
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Use OTableSelectionPage::m_xTable directly instead of
the weld::TreeView& param passed to the handler.
That is the weld::TreeView that the handler is connected to.
This also prepares for adjusting weld::TreeView::m_aRowActivatedHdl
to pass the weld::TreeIter of the activated entry instead of just the
weld::TreeView itself.
Change-Id: I5fd9670adb65ef3110988b0f5b2a95de4ef61915
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203301
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As described for OPropertyInfoService::getPropertyId
in earlier commit
Change-Id: I849cfa251b8be73b9541ad154527fa47c75c26ae
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Apr 2 14:16:23 2026 +0200
propctrlr: Make OPropertyInfoService::getPropertyId static, drop from iface
, also do for this OPropertyInfoService::getPropertyEnumRepresentations:
Drop the method from the abstract base class and make it static in
OPropertyInfoService.
This means that all OPropertyInfoService members are
static now, so there all instances of this class
can be dropped as well. Do so.
Also drop IPropertyInfoService that used to be the
abstract base class previously altogether.
Change-Id: Ic61ed216fff226faa46383d05cb095ebbd156fee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203165
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As described for OPropertyInfoService::getPropertyId
in earlier commit
Change-Id: I849cfa251b8be73b9541ad154527fa47c75c26ae
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Apr 2 14:16:23 2026 +0200
propctrlr: Make OPropertyInfoService::getPropertyId static, drop from iface
, also do for this method: Drop the method from the abstract
base class and make it static in OPropertyInfoService.
Change-Id: I172936700cc1e9e4270cc25ad918068e2f22c1c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203164
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch DefaultEnumRepresentation::m_rMetaData from the abstract
base class to the concrete OPropertyInfoService subclass
that is the only class subclassing IPropertyInfoService&.
Change-Id: Ib508a6b297d8730eb421be325b23b83f9c08d7a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203163
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As described for OPropertyInfoService::getPropertyId
in earlier commit
Change-Id: I849cfa251b8be73b9541ad154527fa47c75c26ae
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Apr 2 14:16:23 2026 +0200
propctrlr: Make OPropertyInfoService::getPropertyId static, drop from iface
, also do for this method: Drop the method from the abstract
base class and make it static in OPropertyInfoService.
Change-Id: I513c8875a14c633e784a22850a62caad8912a733
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203162
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
As described for OPropertyInfoService::getPropertyId
in earlier commit
Change-Id: I849cfa251b8be73b9541ad154527fa47c75c26ae
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Apr 2 14:16:23 2026 +0200
propctrlr: Make OPropertyInfoService::getPropertyId static, drop from iface
, also do for this method: Drop the method from the abstract
base class and make static in OPropertyInfoService.
Change-Id: I7d062587b61cb5d189747ce7e44901e6938f6ed5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203161
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As described for OPropertyInfoService::getPropertyId
in earlier commit
Change-Id: I849cfa251b8be73b9541ad154527fa47c75c26ae
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Apr 2 14:16:23 2026 +0200
propctrlr: Make OPropertyInfoService::getPropertyId static, drop from iface
, also do for OPropertyInfoService::getPropertyTranslation:
Drop the method from the abstract base class and make
static in OPropertyInfoService.
Change-Id: If38d44caed5248eaed8415124123ad8dc9523085
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203160
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This in particular gets rid of an extra indentation level
and that very long lines are wrapped.
Change-Id: If07a7e720d9483ac223117fae850c52a9ba48f97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203159
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The IPropertyInfoService interface/abstract base class
is only subclassed by the final class OPropertyInfoService
and various of its methods are only non-static because they
are currently marked as overriding the purely virtual
methods in the base class.
In order to simplify this, drop the purely virtual
IPropertyInfoService::getPropertyId and make the
OPropertyInfoService method static.
This also allows to make various PropertyHandler methods using
it static as well.
Similar changes will follow for other OPropertyInfoService
methods in upcoming commits. (One method at a time to
make it easier to keep an overview of what each change
does.)
Change-Id: I849cfa251b8be73b9541ad154527fa47c75c26ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203158
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
A deadlock seen with the following call stacks.
Main thread is trying to paint in a timer event, and is waiting for
the FormComponentPropertyHandler's mutex:
ntdll.dll!NtWaitForAlertByThreadId()
ntdll.dll!RtlpWaitOnCriticalSection()
ntdll.dll!RtlpEnterCriticalSectionContended()
ntdll.dll!RtlEnterCriticalSection()
sal3.dll!osl_acquireMutex(_oslMutexImpl * Mutex) Line 65
pcrlo.dll!osl::Mutex::acquire() Line 63
pcrlo.dll!osl::Guard<osl::Mutex>::Guard<osl::Mutex>(osl::Mutex & t) Line 144
• pcrlo.dll!pcr::FormComponentPropertyHandler::getPropertyValue(const rtl::OUString & _rPropertyName) Line 307
pcrlo.dll!pcr::OPropertyBrowserController::impl_getPropertyValue_throw(const rtl::OUString & _rPropertyName) Line 907
pcrlo.dll!pcr::OPropertyBrowserController::propertyChange(const com::sun::star::beans::PropertyChangeEvent & _rEvent) Line 661
cppuhelper3MSC.dll!cppu::OPropertySetHelper::fire(long * pnHandles, const com::sun::star::uno::Any * pNewValues, const com::sun::star::uno::Any * pOldValues, long nHandles, unsigned char bVetoable) Line 733
comphelper.dll!comphelper::OPropertySetAggregationHelper::propertiesChange(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyChangeEvent> & _rEvents) Line 420
cppuhelper3MSC.dll!cppu::OPropertySetHelper::firePropertiesChangeEvent(const com::sun::star::uno::Sequence<rtl::OUString> & rPropertyNames, const com::sun::star::uno::Reference<com::sun::star::beans::XPropertiesChangeListener> & rListener) Line 961
tklo.dll!ControlContainerBase::ImplUpdateResourceResolver() Line 1698
tklo.dll!ControlContainerBase::ImplStartListingForResourceEvents() Line 1675
tklo.dll!ControlContainerBase::setModel(const com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> & rxModel) Line 1428
tklo.dll!UnoDialogControl::setModel(const com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> & rxModel) Line 348
svxcorelo.dll!sdr::contact::`anonymous namespace'::ControlHolder::setModel(const com::sun::star::uno::Reference<com::sun::star::awt::XControlModel> & _m) Line 186
svxcorelo.dll!sdr::contact::ViewObjectContactOfUnoControl_Impl::createControlForDevice(const sdr::contact::`anonymous-namespace'::IPageViewAccess & _rPageView, const OutputDevice & _rDevice, const SdrUnoObj & _rUnoObject, const basegfx::B2DHomMatrix & _rInitialViewTransformation, const basegfx::B2DHomMatrix & _rInitialZoomNormalization, sdr::contact::`anonymous-namespace'::ControlHolder & _out_rControl) Line 1097
svxcorelo.dll!sdr::contact::ViewObjectContactOfUnoControl_Impl::impl_ensureControl_nothrow(const sdr::contact::`anonymous-namespace'::IPageViewAccess & _rPageView, const OutputDevice & _rDevice, const basegfx::B2DHomMatrix & _rInitialViewTransformation) Line 1037
svxcorelo.dll!sdr::contact::ViewObjectContactOfUnoControl_Impl::ensureControl(const basegfx::B2DHomMatrix * _pInitialViewTransformationOrNULL) Line 963
svxcorelo.dll!sdr::contact::`anonymous namespace'::LazyControlCreationPrimitive2D::create2DDecomposition(const drawinglayer::geometry::ViewInformation2D & _rViewInformation) Line 1539
drawinglayercorelo.dll!drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor & rVisitor, const drawinglayer::geometry::ViewInformation2D & rViewInformation) Line 79
svxcorelo.dll!sdr::contact::`anonymous namespace'::LazyControlCreationPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor & rVisitor, const drawinglayer::geometry::ViewInformation2D & _rViewInformation) Line 1523
drawinglayerlo.dll!drawinglayer::processor2d::BaseProcessor2D::process(const drawinglayer::primitive2d::BasePrimitive2D & rCandidate) Line 43
drawinglayerlo.dll!drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(const drawinglayer::primitive2d::BasePrimitive2D & rCandidate) Line 374
drawinglayerlo.dll!drawinglayer::processor2d::BaseProcessor2D::process(const drawinglayer::primitive2d::Primitive2DContainer & rSource) Line 67
svxcorelo.dll!sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo & rDisplayInfo) Line 303
svxcorelo.dll!sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo & rDisplayInfo) Line 128
svxcorelo.dll!SdrPageWindow::RedrawLayer(const o3tl::strong_int<short,SdrLayerIDTag> * pId, sdr::contact::ViewObjectContactRedirector * pRedirector, const basegfx::B2IRange * pPageFrame) Line 422
svxcorelo.dll!SdrPageView::DrawLayer(o3tl::strong_int<short,SdrLayerIDTag> nID, OutputDevice * pGivenTarget, sdr::contact::ViewObjectContactRedirector * pRedirector, const tools::Rectangle & rRect, const basegfx::B2IRange * pPageFrame) Line 304
svxcorelo.dll!SdrPaintView::ImpFormLayerDrawing(SdrPaintWindow & rPaintWindow, sdr::contact::ViewObjectContactRedirector * pRedirector) Line 798
svxcorelo.dll!SdrPaintView::EndCompleteRedraw(SdrPaintWindow & rPaintWindow, bool bPaintFormLayer, sdr::contact::ViewObjectContactRedirector * pRedirector) Line 653
svxcorelo.dll!SdrPaintView::EndDrawLayers(SdrPaintWindow & rPaintWindow, bool bPaintFormLayer, sdr::contact::ViewObjectContactRedirector * pRedirector) Line 726
basctllo.dll!basctl::DlgEditor::Paint(OutputDevice & rRenderContext, const tools::Rectangle & rRect) Line 547
basctllo.dll!basctl::DialogWindow::Paint(OutputDevice & rRenderContext, const tools::Rectangle & rRect) Line 124
vcllo.dll!PaintHelper::DoPaint(const vcl::Region * pRegion) Line 316
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 618
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!PaintHelper::~PaintHelper() Line 553
vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624
vcllo.dll!vcl::Window::ImplCallOverlapPaint() Line 645
vcllo.dll!vcl::Window::ImplHandlePaintHdl(Timer * __formal) Line 668
vcllo.dll!vcl::Window::LinkStubImplHandlePaintHdl(void * instance, Timer * data) Line 649
vcllo.dll!Link<Timer *,void>::Call(Timer * data) Line 105
vcllo.dll!Timer::Invoke() Line 75
vcllo.dll!Scheduler::CallbackTaskScheduling() Line 615
vcllo.dll!SalTimer::CallCallback() Line 53
vclplug_winlo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 169
vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 443
vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 499
vcllo.dll!InnerYield(bool i_bWait, bool i_bAllEvents) Line 389
vcllo.dll!Application::Yield() Line 502
vcllo.dll!Application::Execute() Line 365
sofficeapp.dll!desktop::Desktop::Main() Line 1681
vcllo.dll!ImplSVMain() Line 230
vcllo.dll!SVMain() Line 249
sofficeapp.dll!soffice_main() Line 122
soffice.bin!sal_main() Line 51
soffice.bin!main(int argc, char * * argv) Line 49
soffice.bin!invoke_main() Line 79
soffice.bin!__scrt_common_main_seh() Line 288
soffice.bin!__scrt_common_main() Line 331
soffice.bin!mainCRTStartup(void * __formal) Line 17
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
while the worker thread is holding the mutex and is sending a message
to the main thread synchronously:
win32u.dll!NtUserMessageCall()
user32.dll!SendMessageWorker()
user32.dll!SendMessageInternal(struct HWND__ *,unsigned int,unsigned __int64,__int64,int)
user32.dll!SendMessageW()
vclplug_winlo.dll!WinSalInstance::SendWndMessage_impl(HWND__ * hWnd, unsigned int Msg, unsigned __int64 wParam, __int64 lParam) Line 689
vclplug_winlo.dll!WinSalInstance::SendComWndMessage(unsigned int Msg, unsigned __int64 wParam, __int64 lParam) Line 700
vclplug_winlo.dll!WinSalFrame::ReleaseGraphics(SalGraphics * pGraphics) Line 1052
vcllo.dll!vcl::WindowOutputDevice::ReleaseGraphics(bool bRelease) Line 905
vcllo.dll!vcl::Window::dispose() Line 487
vcllo.dll!ImplBorderWindow::dispose() Line 1614
vcllo.dll!VclReferenceBase::disposeOnce() Line 38
vcllo.dll!VclPtr<ImplBorderWindow>::disposeAndClear() Line 224
vcllo.dll!ScopedVclPtr<ImplBorderWindow>::~ScopedVclPtr<ImplBorderWindow>() Line 351
vcllo.dll!ScopedVclPtrInstance<ImplBorderWindow>::~ScopedVclPtrInstance<ImplBorderWindow>()
vcllo.dll!Dialog::GetDrawWindowBorder(long & rLeftBorder, long & rTopBorder, long & rRightBorder, long & rBottomBorder) Line 1389
tklo.dll!VCLXDialog::getInfo() Line 2302
basctllo.dll!basctl::DlgEdForm::getDeviceInfo() Line 1642
basctllo.dll!basctl::DlgEdObj::TransformFormToSdrCoordinates(long nXIn, long nYIn, long nWidthIn, long nHeightIn, long & nXOut, long & nYOut, long & nWidthOut, long & nHeightOut) Line 351
basctllo.dll!basctl::DlgEditor::AdjustPageSize() Line 1182
basctllo.dll!basctl::DlgEditor::SetDialog(const com::sun::star::uno::Reference<com::sun::star::container::XNameContainer> & xUnoControlDialogModel) Line 351
basctllo.dll!basctl::DlgEditor::ResetDialog() Line 409
basctllo.dll!basctl::DlgEdObj::_propertyChange(const com::sun::star::beans::PropertyChangeEvent & evt) Line 1147
basctllo.dll!basctl::DlgEdPropListenerImpl::propertyChange(const com::sun::star::beans::PropertyChangeEvent & evt) Line 44
cppuhelper3MSC.dll!cppu::OPropertySetHelper::fire(long * pnHandles, const com::sun::star::uno::Any * pNewValues, const com::sun::star::uno::Any * pOldValues, long nHandles, unsigned char bVetoable) Line 733
comphelper.dll!comphelper::OPropertySetAggregationHelper::propertiesChange(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyChangeEvent> & _rEvents) Line 398
comphelper.dll!comphelper::OPropertySetHelper::fire(std::unique_lock<std::mutex> & rGuard, const long * pnHandles, const com::sun::star::uno::Any * pNewValues, const com::sun::star::uno::Any * pOldValues, long nHandles, bool bVetoable) Line 594
comphelper.dll!comphelper::OPropertySetHelper::impl_fireAll(std::unique_lock<std::mutex> & rGuard, long * i_handles, const com::sun::star::uno::Any * i_newValues, const com::sun::star::uno::Any * i_oldValues, long i_count) Line 487
comphelper.dll!comphelper::OPropertySetHelper::setFastPropertyValues(std::unique_lock<std::mutex> & rGuard, long nSeqLen, long * pHandles, const com::sun::star::uno::Any * pValues, long nHitCount) Line 748
tklo.dll!UnoControlModel::setFastPropertyValueImpl(std::unique_lock<std::mutex> & rGuard, long nPropId, const com::sun::star::uno::Any & rValue) Line 1247
comphelper.dll!comphelper::OPropertySetHelper::setFastPropertyValue(long nHandle, const com::sun::star::uno::Any & rValue) Line 393
comphelper.dll!comphelper::OPropertySetAggregationHelper::setFastPropertyValue(long _nHandle, const com::sun::star::uno::Any & _rValue) Line 528
cppuhelper3MSC.dll!cppu::OPropertySetHelper::setPropertyValue(const rtl::OUString & rPropertyName, const com::sun::star::uno::Any & rValue) Line 264
• pcrlo.dll!pcr::FormComponentPropertyHandler::setPropertyValue(const rtl::OUString & _rPropertyName, const com::sun::star::uno::Any & _rValue) Line 465
pcrlo.dll!pcr::OPropertyBrowserController::Commit(const rtl::OUString & rName, const com::sun::star::uno::Any & _rValue) Line 1326
pcrlo.dll!pcr::OBrowserListBox::valueChanged(const com::sun::star::uno::Reference<com::sun::star::inspection::XPropertyControl> & _rxControl) Line 637
pcrlo.dll!pcr::PropertyControlContext_Impl::impl_processEvent_throw(const comphelper::AnyEvent & _rEvent) Line 291
pcrlo.dll!pcr::PropertyControlContext_Impl::processEvent(const comphelper::AnyEvent & _rEvent) Line 272
comphelper.dll!comphelper::AsyncEventNotifierBase::execute() Line 138
comphelper.dll!comphelper::AsyncEventNotifier::execute() Line 155
salhelper3MSC.dll!salhelper::Thread::run() Line 40
salhelper3MSC.dll!threadFunc(void * param) Line 190
sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67
ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void *),1>(void * const parameter) Line 97
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
In this case, there is no reason to hold the mutex so long. It is only
needed to get copies of the object state, so only lock the mutex for
that necessary time frame.
Change-Id: Iab8bedb901295a6936d85de1cfb20efa2ce8a4f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202299
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>