V1048 The 'eAggFunc' variable was assigned the same value. Will be assigned after the switch.
Change-Id: I21d4cb4b0e7427bea56598476ca176cc0a4f7124
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175902
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Declare support for the "Insert Breaks"
"File" -> Printer Settings" -> "Properties" dialog.
This means that native Qt widgets are used for that dialog
now when using the qt5 or qt6 VCL plugin and starting LO with
environment variable SAL_VCL_QT_USE_WELDED_WIDGETS=1 set.
Since this dialog contains tab pages, their .ui files
need to be declared as supported as well.
Change-Id: Ia4360eebf3fed6ab5f78510c866a1703b0db8998
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177923
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The current item and the selected item(s) are
not necessarily the same.
Looking into the gtk and VCL implementations,
weld::TreeView::signal_changed is called
when the selection (not the current item) changes, so
connect to the QItemSelectionModel::selectionChanged signal
instead of the QItemSelectionModel::currentChanged one
in the Qt implementation.
At the point in time that the QItemSelectionModel::selectionChanged
signal gets emitted, QItemSelectionModel::selectedIndexes
returns the newly selected indices while that was not
yet the case with QItemSelectionModel::currentChanged.
For the "Device" tab in the "File" -> "Printer Settings" -> "Properties"
dialog (for which support will be added in an upcoming commit),
this resulted in the PPD values (in the tree view
on the right) not being shown for the actually selected PPD
option/key (in the left tree view), but for the
one selected previously.
(See RTSDevicePage::SelectHdl for the logic filling
the tree view with items, which gets triggered when
weld::TreeView::signal_changed gets called.)
Change-Id: I31ec5aaaa47cd3d4704f25086b24645fb708be0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177922
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Similar to the check done in SwEditWin::MouseButtonDown.
Change-Id: I1a1b8966502a6b1557d424f28cfc1c1ecdf4b65e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177930
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Due to formatting, grapheme clusters can possibly be split across
multiple layouts. Layouts containing split grapheme clusters are created
by laying out the complete string, and extracting only the necessary
glyphs based on source codepoint index.
This approach is good enough for most diacritic cases, but it cannot
handle certain substitution cases where glyphs with advances would be
interleaved with other layouts. Sub-layouts must be contiguous.
This change introduces code to disable grapheme cluster splitting in
these cases that cannot be handled correctly.
Change-Id: I122abbf9c3f8a5efa4c72ad47991d0ad9ff8a8c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177927
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Used e.g. in RTSDevicePage::FillValueBox
(i.e. in the "File" -> "Printer Settings" -> "Properties"
dialog).
Change-Id: Ice39b266b366a6fd6b37b6ece28cee529990dc80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177909
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In fact do not accept anything else than blanks after integer
portion for a fraction.
Change-Id: I29746bb7cd78ecc6a7810e8841bee748589a36e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177899
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
which causes problems on export to docx. Sanitize at the original
import.
Change-Id: I8b9fa86465c455fe872c41386889dc54e38eb9ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177904
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
- weld::Menu doesn't have base with weld::Widget
- use separate container, only one menu per WindowId
- first only send menu and cancel, when user activates
option we will send another request and execute entry
as menu can be blocking
- there is connect_activated way of async setup too
Change-Id: Iea03f82a91ecc19af67b91f85364675c119056ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177722
(cherry picked from commit efeb511607dacce991866bcf328c96a01ab594f9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177852
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
By default, a vcl::Window's XAccessible is its
VCLXWindow (toolkit peer):
css::uno::Reference< css::accessibility::XAccessible > Window::CreateAccessible()
{
css::uno::Reference< css::accessibility::XAccessible > xAcc( GetComponentInterface(), css::uno::UNO_QUERY );
return xAcc;
}
However, that's a virtual method and subclasses can
return a different XAccessible.
MenuFloatingWindow::CreateAccessible returns the
accessible of its menu.
However, winaccessibility's AccTopWindowListener
code was relying on the Window's XAccessible always
being its VCLXWindow.
The VLCXWindow is passed as a param in the
XTopWindowListener methods, and AccTopWindowListener
was querying it for the XAccessible interface, and
then calling XAccessible::getAccessibleContext in
order to retrieve the XAccessibleContext for the
window.
This is incorrect if the Window actually has another
XAccessible.
For the df#164093 scenario with NVDA running, opening and
closing the sidebar popup menu would result in the
VCLXWindow's VCLXWindow::getAccessibleContext menu
getting called, which calls VCLXWindow::CreateAccessibleContext
and the VCLXWindow would keep a reference to the
returned XAccessibleContext and dispose it when
the VLCXWindow itself gets disposed.
However, AccessibleFactory::createAccessibleContext
(called by VCLXWindow::CreateAccessibleContext)
doesn't actually create a new object for the
MenuFloatingWindow's accessible, but returns the
existing accessible object of the PopupMenu, which is
owned by the PopupMenu, not the MenuFloatingWindow,
s.a. previous commit
Change-Id: Ia2931bee23204395e8b3396927acf4fa1d0f077c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Dec 5 11:06:48 2024 +0000
tdf#164093 tdf#157001 a11y: Improve menu window disposal
for more details.
Backtrace of how that accessible context was returned:
1 `anonymous namespace'::AccessibleFactory::createAccessibleContext acc_factory.cxx 305 0x7fffbc160767
2 VCLXWindow::CreateAccessibleContext vclxwindow.cxx 879 0x7fffc0b1bc67
3 VCLXWindow::getAccessibleContext vclxwindow.cxx 2418 0x7fffc0b2670b
4 AccTopWindowListener::HandleWindowOpened AccTopWindowListener.cxx 60 0x7fffe5c32ab6
5 AccTopWindowListener::windowOpened AccTopWindowListener.cxx 119 0x7fffe5c3375e
6 ``anonymous namespace'::VCLXToolkit::callTopWindowListeners'::`2'::<lambda_1>::operator() vclxtoolkit.cxx 2364 0x7fffc0af27ef
7 comphelper::OInterfaceContainerHelper4<com::sun:⭐:awt::XTopWindowListener>::forEach<``anonymous namespace'::VCLXToolkit::callTopWindowListeners'::`2'::<lambda_1>> interfacecontainer4.hxx 349 0x7fffc0ae7f9e
8 `anonymous namespace'::VCLXToolkit::callTopWindowListeners vclxtoolkit.cxx 2359 0x7fffc0afeaed
9 `anonymous namespace'::VCLXToolkit::eventListenerHandler vclxtoolkit.cxx 2295 0x7fffc0b02492
10 `anonymous namespace'::VCLXToolkit::LinkStubeventListenerHandler vclxtoolkit.cxx 2288 0x7fffc0afbdf6
11 Link<VclSimpleEvent &,void>::Call link.hxx 111 0x7fffbfba33d3
12 VclEventListeners::Call vclevent.cxx 47 0x7fffbfba35f1
13 Application::ImplCallEventListeners svapp.cxx 733 0x7fffbfb76dbb
14 vcl::Window::CallEventListeners event.cxx 229 0x7fffbf45f841
15 vcl::Window::ImplSetReallyVisible window.cxx 1331 0x7fffbf566bad
16 vcl::Window::ImplSetReallyVisible window.cxx 1344 0x7fffbf566c7d
17 vcl::Window::Show window.cxx 2336 0x7fffbf56a8d1
18 vcl::Window::Show window.cxx 2349 0x7fffbf56a9ce
19 FloatingWindow::StartPopupMode floatwin.cxx 825 0x7fffbf46a702
20 PopupMenu::Run menu.cxx 3018 0x7fffbf4a6f02
... <More>
When the MenuFloatingWindow gets disposed, its
VCLXWindow is also disposed. Since it incorrectly
assumes it (or its Window) owns the XAccessibleContext,
it disposes that as well:
1 OAccessibleMenuBaseComponent::disposing accessiblemenubasecomponent.cxx 608 0x7fffbf300c82
2 cppu::WeakComponentImplHelperBase::dispose implbase.cxx 104 0x7fffe199964a
3 cppu::PartialWeakComponentImplHelper<com::sun:⭐:accessibility::XAccessibleContext2,com::sun:⭐:accessibility::XAccessibleEventBroadcaster>::dispose compbase.hxx 90 0x7fffdb8d1820
4 VCLXWindow::dispose vclxwindow.cxx 938 0x7fffc0b24012
5 UnoWrapper::WindowDestroyed unowrapper.cxx 302 0x7fffc0cfddc6
6 vcl::Window::dispose window.cxx 220 0x7fffbf56e68f
7 SystemWindow::dispose syswin.cxx 107 0x7fffbf515606
8 FloatingWindow::dispose floatwin.cxx 225 0x7fffbf46b751
9 MenuFloatingWindow::dispose menufloatingwindow.cxx 134 0x7fffbf4bd766
10 VclReferenceBase::disposeOnce vclreferencebase.cxx 39 0x7fffbf7520d9
11 VclPtr<vcl::Window>::disposeAndClear vclptr.hxx 207 0x7fffbf3f98d2
12 PopupMenu::ImplExecute menu.cxx 2947 0x7fffbf4a0ee7
13 PopupMenu::Execute menu.cxx 2834 0x7fffbf49c392
14 MenuButton::ExecuteMenu menubtn.cxx 77 0x7fffbf639f1d
15 MenuButton::MouseButtonDown menubtn.cxx 214 0x7fffbf63a847
16 ImplHandleMouseEvent winproc.cxx 708 0x7fffbf57ca27
17 ImplHandleSalMouseButtonDown winproc.cxx 2338 0x7fffbf57e1af
18 ImplWindowFrameProc winproc.cxx 2683 0x7fffbf57fc07
19 SalFrame::CallCallback salframe.hxx 312 0x7fffbf3443c6
20 ImplHandleMouseMsg salframe.cxx 3415 0x7fffbc818e8f
... <More>
However, the Menu that actually owns the accessible may
still be alive, and then opening the menu again results
in an attempt to make use of the already disposed object,
triggering a crash due to a DisposedException being thrown:
1 RaiseException KERNELBASE 0x7ff808e8b699
2 CxxThrowException VCRUNTIME140 0x7fffef535267
3 comphelper::OCommonAccessibleComponent::ensureAlive accessiblecomponenthelper.cxx 141 0x7fffdb8d1937
4 comphelper::OContextEntryGuard::OContextEntryGuard accessiblecontexthelper.hxx 64 0x7fffbf2fb8eb
5 comphelper::OExternalLockGuard::OExternalLockGuard accessiblecontexthelper.hxx 81 0x7fffbf2fb948
6 OAccessibleMenuBaseComponent::getAccessibleContext accessiblemenubasecomponent.cxx 641 0x7fffbf301337
7 VCLXAccessibleComponent::ProcessWindowChildEvent vclxaccessiblecomponent.cxx 165 0x7fffc0a9596d
8 VCLXAccessibleComponent::WindowChildEventListener vclxaccessiblecomponent.cxx 124 0x7fffc0a96669
9 VCLXAccessibleComponent::LinkStubWindowChildEventListener vclxaccessiblecomponent.cxx 114 0x7fffc0a957f6
10 Link<VclWindowEvent &,void>::Call link.hxx 111 0x7fffbf45f7d3
11 vcl::Window::CallEventListeners event.cxx 300 0x7fffbf45fe0c
12 vcl::Window::ImplSetReallyVisible window.cxx 1331 0x7fffbf566bad
13 vcl::Window::ImplSetReallyVisible window.cxx 1344 0x7fffbf566c7d
14 vcl::Window::Show window.cxx 2336 0x7fffbf56a8d1
15 vcl::Window::Show window.cxx 2349 0x7fffbf56a9ce
16 FloatingWindow::StartPopupMode floatwin.cxx 825 0x7fffbf46a702
17 PopupMenu::Run menu.cxx 3018 0x7fffbf4a6f02
18 PopupMenu::ImplExecute menu.cxx 3005 0x7fffbf4a1707
19 PopupMenu::Execute menu.cxx 2834 0x7fffbf49c392
20 MenuButton::ExecuteMenu menubtn.cxx 77 0x7fffbf639f1d
... <More>
To fix that, adjust winaccessibility's
AccTopWindowListener to no longer just use
the VCLXWindow for the accessible, but
get the vcl::Window for the VCLXWindow and
query it's actual XAccessible using
vcl::Window::GetAccessible().
This fixes the tdf#164093 crash. The problem of
tdf#157001 where items in the popup menu of Calc's organize
template dialog are only announced the first time the menu
is opened still remains for now, but is also somehow
related to the MenuFloatingWindow being disposed.
(No longer reproducible when no longer calling
the base class FloatingWindow::dispose from
MenuFloatingWindow::dispose in a local test,
still needs further analysis.)
Change-Id: Ic96d2c95128af144c7769aac40707299b1c80f8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177889
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
There's no need to have local raw pointer variables
in addition to the existing References.
Replace all uses of the former by using the latter
and drop duplicate checks.
Change-Id: I1339dabecbe8e1652e49df8ecd5ce2749b897f47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177888
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Window::GetSystemData should never throw an
exception, so there's no need for exception
handling here. Also, return early if the
system data is null.
Change-Id: I65794f10019d0c2fb5cc7150500b551c31cc2a08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177887
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... instead of a pointer, to make clear
that this is always non-null.
Change-Id: I4c8676913b2507f077d8a66973ab5f95e73cb497
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177886
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of a pointer, to make clear
that this is always non-null.
Change-Id: Ic0f92e672b08494cf3bfaa9a956cb78170bc1ad5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177885
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
No need to have `pAccessibleContext` as a raw
pointer, just use the `xContext`. And that one
has already been checked for being a non-empty
Reference above.
Change-Id: I15d7e70ddbc8b260e5e1bc0eb4e190c54d6a2ea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177884
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In MenuFloatingWindow::dispose, unset the accessible
before calling the base class implementation, to prevent
the accessible from getting disposed there as well.
This is necessary because the MenuFloatingWindow
doesn't create (and therefore own) its accessible
object, but returns that from its menu in
MenuFloatingWindow::CreateAccessible. Therefore,
the PopupMenu as the owner is responsible for disposing the
accessible as well, not the MenuFloatingWindow.
This logic was already implemented in Menu::dispose,
but that doesn't help in cases where the MenuFloatingWindow
gets disposed independently.
In Menu::dispose, drop the extra logic
and just call `m_pWindow.disposeAndClear`
so that MenuFloatingWindow::dispose can
take care of everything that's needed.
(For the MenuBar case, MenuBar::dispose
calls MenuBar::ImplDestroy, which unsets
Menu::m_pWindow, so other than for PopupMenu,
this change to MenuBar::ImplDestroy method doesn't
make a difference for that class.)
Don't dispose the current Menu::m_pWindow in
PopupMenu::FinishRun, but instead in
PopupMenu::ImplExecute (if set) before assigning
a new one, to ensure that the old one gets disposed.
Drop the
SAL_WARN_IF(GetWindow(), "vcl", "Win?!");
because that case is handled fine now. Without this
change in place, I saw that warning getting triggered
while debugging (potentially because PopupMenu::FinishRun
never got reached as the menu didn't show, maybe due to
switching focus to the IDE when reaching a breakpoint
or different timing,...).
This commit by itself doesn't yet fix the crash
from tdf#164093 seen on Windows with NVDA running
because the menu's accessible still incorrectly gets
disposed by the MenuFloatingWindow's VCLXWindow
(toolkit window peer). That will be addressed
in a separate commit.
Change-Id: Ia2931bee23204395e8b3396927acf4fa1d0f077c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177883
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It's unclear to me why the list child's accessible should
be passed instead of the window's here.
In addition, AccessBridgeHandleExistingWindow is only relevant
when the AT brigde is started, i.e. for example when starting
a screen reader while LO has been running already. This makes
this look even less relevant and unclear to me why special handling
would be applied for that case, but not when a combobox popup
is shown when a11y has been active before already.
Change-Id: Ie7b16de36889e2432f6ac9455ab297ca16d3b26e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177882
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The method only gets called from AccessBridgeUpdateOldTopWindows
which always passes a non-null window.
Change-Id: I7d6d4effb75c722af6176257b8f296b5a77734cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177880
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Application::GetTopWindow also takes a tools::Long param,
so there's no reason to cast to sal_uInt16.
Change-Id: Ic592262bee8173329986ccb83298a26deb3586b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177879
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This was using a weak reference when the comment
was added in
commit 9b34eb7c85
Author: Frank Schönheit <fs@openoffice.org>
Date: Thu Apr 25 10:24:33 2002 +0000
#98750# be an XEventListener at the AccessibleContext
, but later changed to be a hard reference in
commit 23d689d4e4
Author: Thomas Benisch <tbe@openoffice.org>
Date: Thu Nov 7 16:19:24 2002 +0000
#103674# change the reference to the accessible context from weak to hard
. Unfortunately that commit only references a StarDivision
internal ticket, so the exact reason remains unclear,
but at least update the comment.
Change-Id: Icdc9aec97647ae05ae7fb3f2bdc1be43c3a62619
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177848
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
follow up for f5ebf512ccd3d5ae3af5fe706b411a85fa19182d
now same actions are performed on all the dialogs
Change-Id: I6531a766327dda106770a2c513ebd492dea7c655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176933
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 2fba6df7242586870988b62909156538b42c2bc0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177892
Tested-by: Jenkins
It turns out the majority of getCommandValues() return values specify a
commandName and a commandValues key, which is helpful when we don't
track the request for this reply.
Fix .uno:Signature to do the same for consistency.
Change-Id: I46ffe5c36047ef2b59113d0221a1874ba28d335b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177857
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
which causes problems on export to docx. Sanitize at the original
import.
Change-Id: I3b5521dac6a2b6926db6362d33500b11f0a69098
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177869
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
but still has the same problem as the gtk3 iconview with reporting
positions when scrolled
a problem since:
commit a36a58933a
CommitDate: Wed Dec 4 07:40:30 2024 +0100
sd: convert sidebar masterpage panels from drawingview to iconview
Change-Id: Ice549b40d88c5d2063e37ccb63490e3537736d39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177855
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
A crash was reported in HasOnlyOneListener, with the following call stack:
ntdll.dll!KiUserExceptionDispatch()
swlo.dll!SwModify::HasOnlyOneListener() Line 204
swlo.dll!SwFormatField::~SwFormatField() Line 142
swlo.dll!SwHistorySetTextField::`scalar deleting destructor'(unsigned int)
swlo.dll!std::default_delete<SwHistoryHint>::operator()(SwHistoryHint *) Line 3090
swlo.dll!std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>::{dtor}() Line 3198
swlo.dll!std::destroy_at(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * const) Line 311
swlo.dll!std::_Default_allocator_traits<std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::destroy(std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>> &) Line 688
swlo.dll!std::_Destroy_range(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * _First, std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * const) Line 905
swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::_Destroy(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * _Last, std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> *) Line 1667
swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::_Tidy() Line 1751
swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::~vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>() Line 699
swlo.dll!SwUndoSaveContent::~SwUndoSaveContent() Line 740
swlo.dll!SwUndoDelete::~SwUndoDelete() Line 633
swlo.dll!SwUndoDelete::`scalar deleting destructor'(unsigned int)
svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
svllo.dll!std::destroy_at(MarkedUndoAction * const) Line 311
svllo.dll!std::_Default_allocator_traits<std::allocator<MarkedUndoAction>>::destroy(std::allocator<MarkedUndoAction> &) Line 688
svllo.dll!std::_Destroy_range(MarkedUndoAction * _First, MarkedUndoAction * const) Line 905
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Destroy(MarkedUndoAction * _Last, MarkedUndoAction *) Line 1667
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Tidy() Line 1751
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::~vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>() Line 699
svllo.dll!SfxUndoArray::{dtor}() Line 1389
svllo.dll!SfxListUndoAction::~SfxListUndoAction() Line 1318
svllo.dll!SfxListUndoAction::`vector deleting destructor'(unsigned int)
svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
svllo.dll!std::destroy_at(MarkedUndoAction * const) Line 311
svllo.dll!std::_Default_allocator_traits<std::allocator<MarkedUndoAction>>::destroy(std::allocator<MarkedUndoAction> &) Line 688
svllo.dll!std::_Destroy_range(MarkedUndoAction * _First, MarkedUndoAction * const) Line 905
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Destroy(MarkedUndoAction * _Last, MarkedUndoAction *) Line 1667
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Tidy() Line 1751
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::~vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>() Line 699
svllo.dll!SfxUndoArray::{dtor}() Line 1389
svllo.dll!SfxListUndoAction::~SfxListUndoAction() Line 1318
svllo.dll!SfxListUndoAction::`vector deleting destructor'(unsigned int)
svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
svllo.dll!std::destroy_at(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * const) Line 311
svllo.dll!std::_Default_allocator_traits<std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::destroy(std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>> &) Line 688
svllo.dll!std::_Destroy_range(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * _First, std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * const) Line 905
svllo.dll!std::vector<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>,std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::_Destroy(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * _Last, std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> *) Line 1667
svllo.dll!std::vector<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>,std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::clear() Line 1442
svllo.dll!svl::undo::impl::UndoManagerGuard::~UndoManagerGuard() Line 325
svllo.dll!SfxUndoManager::ImplClearRedo_NoLock(const bool i_currentLevel) Line 468
swlo.dll!sw::DocumentContentOperationsManager::InsertPoolItem(const SwPaM & rRg, const SfxPoolItem & rHt, const SetAttrMode nFlags, const SwRootFrame * pLayout, SwTextAttr * * ppNewTextAttr) Line 3694
swlo.dll!SwXTextField::attach(const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> & xTextRange) Line 1972
swlo.dll!SwXText::insertTextContent(const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> & xRange, const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextContent> & xContent, unsigned char bAbsorb) Line 606
mscx_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 214
mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 430
binaryurplo.dll!binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny * returnValue, std::vector<binaryurp::BinaryAny,std::allocator<binaryurp::BinaryAny>> * outArguments) Line 239
binaryurplo.dll!binaryurp::IncomingRequest::execute() Line 79
binaryurplo.dll!request(void * pThreadSpecificData) Line 84
cppu3.dll!cppu_threadpool::JobQueue::enter(const void * nDisposeId, bool bReturnWhenNoJob) Line 101
cppu3.dll!cppu_threadpool::ORequestThread::run() Line 169
cppu3.dll!threadFunc(void * param) Line 190
sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67
I don't know why pType->Which() succeeded before the broadcast and reset,
and pType->HasOnlyOneListener() crashed; field destructors themselves do
not seem to destroy their types (except SwDBField, which is handled here
explicitly). My blind guess is, that a change could happen in broadcast.
Change-Id: I5c7f07da2e1283510bce3a3e3e80b6f8d849f38b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177854
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
no need to copy things to a std::deque, it is quite straightforward to
just iterate over the SwNodes structure.
Shaves off about 30% of the time spent processing post-load.
Change-Id: I852079c18738299be04cec52b82e0f6949f2d81c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177837
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
The option also affects hyphen and the label should reflect this
Change-Id: I5e092f8c5d67c1c039de709d024c89481b40a82d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177841
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Previously, Writer was not correctly terminating layout contexts at the
starts of small caps spans. This could cause incorrect character
placement in certain cases.
Regression since:
Commit 30d376fb7d
"tdf#61444 Correct Writer text layout across formatting changes"
and
Commit ab0a4543ca
"tdf#124116 Correct Writer text shaping across formatting changes"
Change-Id: I863b9b66356eb0a9efb5bbdc75e80b43d56aaaf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177839
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
In QtInstanceWidget, connect to the QApplication::focusChanged
signal [1] and when either the old or the new focus widget
is the one belonging to this QtInstanceWidget, notify
about the lost/gained focus.
With this in place, SvxSearchDialog::FocusHdl_Impl
now gets called in a WIP branch where support for the
"Find and Replace" dialog is declared when moving
focus into one of the comboboxes in that dialog.
[1] https://doc.qt.io/qt-6/qapplication.html#focusChanged
Change-Id: I15190cf9b0d2e72d78a57f58da7ff2ebd1e7a6d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177835
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to what already exists in most subclasses,
add signal_<event_name> methods to call the handlers
and use these in the subclasses instead of calling
the handlers directly.
Change-Id: I6b79ddd859b360e947d97ada57f1573a276d6177
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177834
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Also add Q_OBJECT macros for all subclasses
that didn't have them and run moc for them, too.
Change-Id: Ia42ee7d02b68d54df308d33c88bf286468bfa68f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177833
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This e.g. gets called when pressing the "Find Next" button
in the "Find and Replace" dialog.
Change-Id: I30e33d52d19b0afe44564486bfa79e3b500ae856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177832
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As the comment for weld::ComboBox::connect_changed
(in vcl/include/weld.hxx) says:
/* m_aChangeHdl is called when the active item is changed. The can be due
to the user selecting a different item from the list or while typing
into the entry of a combo box with an entry.
Use changed_by_direct_pick() to discover whether an item was actually explicitly
selected, e.g. from the menu.
*/
void connect_changed(const Link<ComboBox&, void>& rLink) { m_aChangeHdl = rLink; }
QComboBox::currentIndexChanged is not emitted while
typing in an editable combobox, so connect to the
QComboBox::editTextChanged signal in addition.
Also, hold the SolarMutex when calling the signal handler.
QtInstanceComboBox::changed_by_direct_pick isn't implemented
yet, but would trigger an assert when called, so this doesn't
go unnoticed at least.
Witht this commit in change, typing in the "Find"
combobox in the "Find and Replace" dialog in a WIP
branch declaring support for that dialog now results
in the buttons getting enabled or disabled as expected
(disabled when text is empty, enabled when non-empty).
Change-Id: I9b89b3a3c8b5ed7ebdeda7b486bdbf2f7e54fd86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177831
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Not doing so would e.g. trigger an assert when
toggling the "Match case" checkbox in the "Find and Replace"
dialog in a WIP branch where support for that dialog with
native widgets is declared.
Change-Id: I5dc95e81e81bceaf258ecba6e55dfa280dfdd572
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177830
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reuse the logic previously implemented in
QtInstanceEntry::set_message_type by moving it to a
static helper method that takes a QLineEdit* param,
and for QtInstanceComboBox::set_entry_message_type,
pass the combo box's line edit.
Change-Id: I8e81c9473da294d2a8c863ed143d735c30ade2a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177829
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
