triggers when running
make CppunitTest_sc_macros_test CPPUNIT_TEST_NAME=testMacroButtonFormControlXlsxExport
under an ASAN build with detect_leaks=1
VbaEventsHelperBase registers listeners, which creates a ref-count cycle,
so it needs to implement the XComponent dispose() mechanism.
While we are at it, fix the same issue in SwDoc
Change-Id: Id1e24addf9788615d77a0976f6fe050d27421bb2
(cherry-pick manually from commit I9bfb72bc1c3df42229240f828add138aace3fa4c)
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1930
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Change-Id: I764316c5718d3b9b78bc2f54d1024249964f5724
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205021
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
V1037 Two or more case-branches perform the same actions. Check lines: 632, 642. But it seems FRAME case was omitted, based on the above switch (line 591).
Change-Id: I781aa8b47bdc969fa8e3e20297c94da71919a33f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175351
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
I had done these a while ago, when I looked into extending loplugin:ostr to do
more automatic rewriting, and these were places where I needed to do something
manually, for one reason or another, because the automatic rewriting would not
pick it up correctly.
However, I got distracted, and a wholesale automatic rewrite would still run
into cases where an _ostr/_ustr instance from a library's .rodata would still be
referenced after the library has already been dlcose'd. So I never came around
to finishing all that.
But there appears to be renewed interest in (automatic) rewritings here now, so
it probably makes sense if I share this part of my work anyway.
Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
The ::Put methods at SfxItemSet had an extra WhichID
parameter that was not really documented, but I would
guess often asked why it exists: An extra WhichID, just
called 'nWhich' (which makes things NOT clearer). That
is 'strange' since the Item given to be put already
internally has a WhichID, so why a 2nd one?
If you were really interested and read all that code
(no, no comments on that anywhere) you might know
that this a kind of 'Target-WhichID' under which
the Item shall be put to the ItemSet. Since this
is unclear for most people it is even dangerous and
explains why so many code places just hand over the
WhichID requsted from the Item that already gets
handed over.
To make it short: I removed that. For the 19 places
where this was really needed I added a new method
besides ::Put called ::PutAsTargetWhich that takes that
extra WhichID (now called TargetWhich) and takes the
needed actions. These are quite some because that may
be combined with the bPassingOwnership flag, see new
SfxItemSet::PutImplAsTargetWhich method.
This makes usage of ItemSets/Items less dangerous. It
also simplifies and thus makes safer the central helpers
implCreateItemEntry/implCleanupItemEntry which have some
less cases to handle.
Debugged the failing UnitTests showed that there is
an incarnate Item != SfxVoidItem that causes problems.
I checked for errors in the change, but no luck.
Afterr some time I found out that a ::Clone
implementation caused the problem: These need to
also copy the WichID of the original, but the
SfxFrameItem failed to do so. This did not cause
problems in the former version because
implCreateItemEntry was designed to set a missing/
different WhichID.
I corrected that in SfxFrameItem, also removed not
needed costructor that caused that. Also added a
SAL_WARN and a correction in implCreateItemEntry.
I could have added an assert (did so for running
local UnitTests), but should be enough.
NOTE: When hunting for Items except SfxVoidItem
that get crerated using a WhichID '0' i learned
that this indeed happens: There are some (5) calls
to SfxRequest::SetReturnValue that incarnate an
SfxBoolItem with WhichID '0' (ZERO). This is not
good and I think about how to change that...
Change-Id: I9854a14cdc42d1cc19c7b9df65ce74147d680825
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162124
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
(*) Make all of it use a "Scoped" paradigm
(*) pass by value, no need to allocate on heap
(*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods.
(*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places.
Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 7fc6063914.
sberg noticed that there is a difference now:
there's a subtle difference now, in that if y was null originally, it would have thrown a (caught) exception, whereas now it will crash in the y.query<X>() call.
Change-Id: Idbb5a08d635d15b5ca63f4822eddf05fb0a5afa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
It has been always typedef'd to basegfx::B2DPoint since:
commit 5e218b5c51
Date: Wed Jan 12 21:19:32 2022 +0000
always use B2DPoint for DevicePoint
Change-Id: I9f5202d5a71c77dd79f1759923917c26bf68a9af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154632
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
sometimes it returns a relative position, sometimes an absolute
position.
Rather have two different methods with names that match what
they return.
Change-Id: Ie1e73c6be1c797fd59934c96866d1fef1f972b35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154653
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Originally, CentimetersToPoints was implemented as a base method for
Writer and Calc. They are both using the same implementation,
which is correct for Writer, but wrong for Calc.
Since their behavior should be different,
I remove the base method and implement a correct one for Calc.
Change-Id: If957accdd9be86a96ca6fb711502e49a79bf3223
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148745
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Enum to store if document is Writer or Calc because font colors are treated
differently depending on this:
In writer the colors come in as RGB but in calc they are in BGR and both palettes
are in RBG so we only need this conversion for calc.
Includes testdoc for calc - to show this still works
Change-Id: I79d9d585dbfc527c0781543ce1f1095c4db190b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144788
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I913565ccd93472f2a8893c4251e80d0309827c34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144633
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I4a66df07f2e768ee3203b730b50be4b9ec6a01a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144634
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The unit test just consists of adding a
"WordBasic.MsgBox()" to the vba code in testVBA.docm.
make CppunitTest_sw_macros_test
or just open the file manually for an easy-to-run experience.
Change-Id: I38edfee42649fcc85f0f535a2c9861c45038fa0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141347
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
A review by Stephan Bergmann made me re-think adding a separate
event for this. It really is only one event and not two
(or three as I initially imagined). In the end, I like this better
because it highlights the difference between Excel and Word
by keeping all the differentiating logic in one place.
The inability to properly document the purpose of these new events
was the impetus to redesign this. Thanks Stephan for the prompt.
Change-Id: Ic2d461c13c4a52e279224cb485d2b6c4a3c57b54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141233
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Unlike Word, ThisWorksheet cannot hold auto-running
subroutines for Open/Close/New.
This fixes a LO 7.4 regression caused by
commit beb6c62e99.
Change-Id: Idb8f72775d9392b306cb924ee776821272b12f3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141127
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Note: this should NOT apply to Document_Open which normally
is a private subroutine and runs fine as private.
I tested and it DOES apply to all three version of AutoOpen:
-ThisDocument.AutoOpen,
-<AnyModule>.AutoOpen,
-AutoOpen.Main
Note: this is different from Excel.
Private Auto_Open runs just fine there.
Change-Id: If10c8c90c35275c2b14dc2e15fb357674fc580b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141114
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
This is the lowest priority way of running AutoOpen,
and it only applies to Word, not Excel.
There is some code in basic/source/classes/sb.cxx
that was somewhat finding this before it got lost in LO 7.4
with commit beb6c62e99.
TODO: these AutoOpens should only run with a public sub,
not a private one.
Change-Id: I8a733cde13f96636942d84a0b05520692aac3e52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141094
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Noel Grandin