COMPMOD_RESPREFIX=abp was unused ever since initial commit in 2001.
COMPMOD_NAMESPACE was used to set the namespace name qualifier of
the helper in componentmodule.hxx to the extension's namespace name.
I don't see why this is necessary as the helper is always compiled in
a separate extension library.
Change-Id: I287607008db3dc0ebc32731536747a921c91807d
Reviewed-on: https://gerrit.libreoffice.org/39184
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...deriving from VclReferenceBase. Complicated by the fact that the argument
type may be incomplete at the time of template instantiation. So this approach
may be less precise than the change to loplugin:vclwidgets from
cbf5b21f2a "Catch some misuses of VclPtr
construction" when the argument type becomes complete later in the comilation
unit. However, this approach would also catch the two misuses in UnoControls
found by cbf5b21f2a, so go with this approach for
now and revert the change to loplugin:vclwdigets.
Change-Id: I7888f23d2b9e2db81ae2ce4bf4c8277912317685
Reviewed-on: https://gerrit.libreoffice.org/31966
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
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>
...they don't cause any change in behavior, likely they predated Noel's figuring
out the template part of containsWindowSubclass
Change-Id: I0d5b6bd7f228acef9a0ce1c85fe98fbab89bd7a8
...as a member of ImplCommandButtonData (vcl/source/control/button.cxx), no need
to falsly warn "OutputDevice subclass 'rtl::Reference<VclStatusListener<Button>>'
declared as a pointer member, should be wrapped in VclPtr [loplugin:vclwidgets]"
Probably loplugin:vclwidgets should enable shouldVisitTemplateInstantiations()
and not try to second-guess whether an OutputDevice can be a template argument.
Change-Id: Ia8feb1b1d7504941c35dfbf0aa02dc6a7dd818a0
Just use a Link, or rather std::function to set a member in the tab
page. Unfortunately loplugin:vclwidgets complains about the new member.
Change-Id: Ie2f9cb73c38292d02057d43b12694c6609fa0db8
sometimes we need to call clear() instead, and there is no
automatic way of figuring this out
Conflicts:
compilerplugins/clang/vclwidgets.cxx
Change-Id: Iad96342ce3fdb3fa2f548270392aa00e19fec599
by using a new utility method in vcl::Window
This means that we don't have to make all our dispose
methods safe to call more than once.
Change-Id: I2110c7de4a86c70fdc97dd8fd318c86b56865374
