because those styles are "pseudo-styles" and a new one cannot be
added. The possibility is supposed to be disabled, and it is
disabled in the floating stylelist. The old code assumes there
can only be one of these stylelists and when a stylelist
queries if the "new" should be disabled the callback asks
the stylelist what family is selected, but only asks the floating one.
So, floating closed, sidebar open, the new is not disabled.
Implement the ancient TODO now that we have to. Instead of asking
the stylelist what family is selected, query the frame for what
is the current SID_STYLE_FAMILY as set by whatever is the active
stylelist.
What's disturbing is the SID_STYLE_FAMILY values are not SfxStyleFamily, but
indexes that have to be mapped to SfxStyleFamily. I bet there are a pile of
bugs around that, especially with little islands of different conversion
codesites
Change-Id: I85c8032d7c26ae6eea245685748f89b2a860e767
==3768== 512 bytes in 1 blocks are possibly lost in loss record 25,532 of 28,010
==3768== at 0x4A06965: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3768== by 0xB52FA41: __gnu_cxx::new_allocator<bool>::allocate(unsigned long, void const*) (new_allocator.h:104)
==3768== by 0xB52EC00: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_allocate_node() (stl_deque.h:533)
==3768== by 0xB52DE4E: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_create_nodes(bool**, bool**) (stl_deque.h:627)
==3768== by 0xB52C624: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_initialize_map(unsigned long) (stl_deque.h:601)
==3768== by 0xB52ACA0: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_Deque_base(std::allocator<bool> const&, unsigned long) (stl_deque.h:461)
==3768== by 0xB5296D3: std::__cxx1998::deque<bool, std::allocator<bool> >::deque(std::allocator<bool> const&) (stl_deque.h:791)
==3768== by 0xB52840E: std::__debug::deque<bool, std::allocator<bool> >::deque(std::allocator<bool> const&) (deque:73)
==3768== by 0xB52786B: framework::UndoManagerHelper_Impl::UndoManagerHelper_Impl(framework::IUndoManagerImplementation&) (undomanagerhelper.cxx:221)
==3768== by 0xB525882: framework::UndoManagerHelper::UndoManagerHelper(framework::IUndoManagerImplementation&) (undomanagerhelper.cxx:879)
==3768== by 0x6872683: sfx2::DocumentUndoManager_Impl::DocumentUndoManager_Impl(sfx2::DocumentUndoManager&) (docundomanager.cxx:88)
==3768== by 0x6870FB6: sfx2::DocumentUndoManager::DocumentUndoManager(SfxBaseModel&) (docundomanager.cxx:227)
==3768== by 0x687A272: SfxBaseModel::getUndoManager() (sfxbasemodel.cxx:1677)
==3768== by 0x260E562A: (anonymous namespace)::getUndoManager(com::sun:⭐:uno::Reference<com::sun:⭐:frame::XFrame> const&) (PagePropertyPanel.cxx:74)
==3768== by 0x260E6C60: sw::sidebar::PagePropertyPanel::PagePropertyPanel(Window*, com::sun:⭐:uno::Reference<com::sun:⭐:frame::XFrame> const&, SfxBindings*) (PagePropertyPanel.cxx:189)
==3768== by 0x260E593C: sw::sidebar::PagePropertyPanel::Create(Window*, com::sun:⭐:uno::Reference<com::sun:⭐:frame::XFrame> const&, SfxBindings*) (PagePropertyPanel.cxx:101)
The SfxBaseModel creates the DocumentUndoManager on demand at
sfx2/source/doc/sfxbasemodel.cxx:1685
m_pDocumentUndoManager is a rtl::Reference but debugging into the
acquire/release I see that the
DocumentUndoManager::acquire/DocumentUndoManager::release forward to those of
SfxModelSubComponent which forward them to its rModel without doing anything
else, so the implementations of
DocumentUndoManager::acquire/DocumentUndoManager::release don't actually do
anything directly to the DocumentUndoManager itself so there is nothing that
will really release it.
Either the rModel needs to explicitly destroy it somehow, given that the
acquire/release delegate responsibility to it, or the whole thing is addled.
I rather feel it's addled, so implement as a normal WeakImplHelper1, but
cowardly in addition also keep acquire/release on the rModel.
Change-Id: Ib52544a9276fd8d9d489ad6b6afda12498cc39fa
regression from 0c17ccc493
I think it might actually make more sense for SetName to always Reindex
and have another SetNameNoReindex for selective use where its known
safe to get away with it
Change-Id: I6bf7e1f45130f741954ab525b838f3ac5ff61a89
A simplified version of the semantic match that finds this problem is
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r1@
statement S;
position p,p1;
@@
S@p1;@p
@script:python r2@
p << r1.p;
p1 << r1.p1;
@@
if p[0].line != p1[0].line_end:
cocci.include_match(False)
@@
position r1.p;
@@
-;@p
// </smpl>
Change-Id: Ib9708d37fbb4c6060f88d5dae3814a2d37b2091e
Reviewed-on: https://gerrit.libreoffice.org/9493
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Now that we have default values for Exception constructor params,
remove lots of boilerplate code.
Change-Id: I620bd641eecfed38e6123873b3b94aaf47922e74
Detect arguments larger than 64 chars passed by value.
Change-Id: I9b0ea9ccb99d115984a26eab67c9cf6afd5f6cae
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
It looks like commit dda842bec3
wanted to #ifdef this Execute_Impl() call but somehow duplicated it.
Change-Id: I745e16cb0be19cf38eb70dd261204c879aa6986e
In the fine tradition of our enterprise-grade code base, this lets the
check in SfxCommonTemplateDialog_Impl::Execute_Impl() do an early
return if the "this" instance has signalled its untimely demise even if
there are multiple calls of Execute_Impl() on the stack; extending
the scheme with further epicycles to make it work if the Execute_Impl()
calls happen on 2 different threads is left as an exercise for the
interested reader.
(regression from bcc52fb2ebdf77a1cc089857775fd742085b45b6)
Change-Id: I1d9f0d82bf6d9f5da8f9bd2be57d01937d71fd26
sfx2::DocumentInserter::CreateMediumList() creates a SfxFilterMatcher
that should match Writer filters only, but actually Calc filters may be
returned; check that the document service matches.
(regression from 3da8f36805)
Change-Id: I6208d38c1110355105aa5d1ffa1b57142193a4d7
