Also remove the tools/solar.h included from tools/debug.hxx. The include of solar.h
header was necessary in some cases because of a macro or a typedef that was needed.
Change-Id: Ia6e15d5c2571c58c9e9138b0d0a7f08ae88053c9
Reviewed-on: https://gerrit.libreoffice.org/11075
Reviewed-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Tested-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
... by replacing the following 3 classes with typedefs of std::vector:
SfxObjectShellArr_Impl / SfxViewFrameArr_Impl / SfxViewShellArr_Impl
and the following 4 with typedefs of boost::ptr_vector:
SfxChildWinFactArr_Impl / SfxMenuCtrlFactArr_Impl /
SfxStbCtrlFactArr_Impl / SfxTbxCtrlFactArr_Impl
Change-Id: I1754bd19ec418a3e7ba5c47fb6d8568e8fca9b29
Reviewed-on: https://gerrit.libreoffice.org/10891
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
The callers in dispatch.cxx use methods that were removed by commit
a1ce4fb4f0dbc3c4141f510e5b2b732a24d862c8 - not sure if this warning is
useful or not.
Change-Id: I8bb654de8e26c054318dd2037055a85d013c8bfa
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2
...and also corresponding param of CreateTabPage function type and corresponding
Craete functions. There were some call sites that passed undefined "null
pointer references" and SfxTabPage internally uses a pointer member pSet that is
checked for null anyway.
Change-Id: I4eb3636155eac46c9c9d26e6e6e842e85d7e95af
...there was a call site that passed undefined "null pointer reference"
(apparently in a case where the passed argument was actually unused)
Change-Id: I663d4264b7a84f44ca69c732f3bc502f614b2b2a
...there were a number of call sites that passed undefined "null pointer
references" (apparently in cases where the passed argument was actually unused)
Change-Id: I19799e90f0cd8e98367782441a5ea9df27b59830
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
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
...so declare them as such. This avoids the recurring mistake of storing such
IDs as sal_uInt32, truncating in 64 bit environments, causing RemoveUserEvent to
potentially not remove the event, it thus firing "too late" and probably causing
a crash.
While at it, consolidate the trivially unnecessary overloads of both
Application::PostUserEvent and Window::PostUserEvent. And in each of them, it
looks like deleting the mpLink member was missing from the failure branch.
Change-Id: Iab13afbb06e12ac15dec6a6b5b85a7e402a3c654
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
Apparently this tool was available for early versions of NT; googling
finds a caplib.zip from 1992 but that is missing the CAP.dll so there's
no way to use this anyway.
http://cd.textfiles.com/cica/cica9308/UNZIPPED/NT/CAPLIB/CAP.TXT
Change-Id: I4718af0e175b78bcdad38bbca0fc9579b3b12111
