Change-Id: I0a15b3567718d08edb4405146f6172c3939e06c1
Reviewed-on: https://gerrit.libreoffice.org/8552Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>

R for Row, C for Column, P for Page, and D for Data fields.

Change-Id: I4e29fcdf77a17498d9325a09f0b21154cab04f83

Change-Id: I3e8ce585b29619061b18ab1ab8f0cf6c7d421074

Change-Id: I12a50d0028164c37d06ff846bfbeff56a4591d12

Change-Id: Ie8cdcf4ad0ffe52024fd5cfe33073abfc6aadca8

f70d0343 "coverity#1158232 have a stab at
silencing warning with function markup" claimed that NamedDBs::insert always
takes ownerhip of its argument, but boost::ptr_set::insert(std::auto_ptr<U> x)
simply calls insert(x.release()), so only takes ownership when it returns true.

ScDBDocFunc::AddDBRange (sc/source/ui/docshell/dbdocfun.cxx) relies on this
behavior, deleting the argument when insert failed.

ScDBDocFunc::RenameDBRange (sc/source/ui/docshell/dbdocfun.cxx) relied on this
behavior, deleting the argument when insert failed, until
f55cc330 "Fixed the fallout of the changes in
ScDBCollection" removed the delete (presumably in error?).  I put it back in
now.

All other uses of NamedDBs::insert ignored the return value (witnessed with
SAL_WARN_UNUSED_RESULT).  Some are insert-if-not-found cases, where I added
asserts now (Sc10Import::LoadDataBaseCollection,
sc/source/filter/starcalc/scflt.cxx, is not entirely clear to me, so I added a
TODO), while others would have potentially leaked the argument, in which cases I
fixed the code.

Change-Id: Iad40fbeb625c8ce6b0a61cbf16298d71cdc7de80

Change-Id: I9040a1262b31f8d0f19594b6efcf12b2c38be7be

Change-Id: I5f78d97bcd55c0db71d7c5e3383678586c2cf392

Change-Id: I513aeeabbb4d6fc48b6a95e034c311a454dd5ca7

Change-Id: Ia58af7d32904de01fdb5291203938c748cae94c6

Change-Id: I767c60733b39de02935de8be8dd9d3e351a38cab

Change-Id: I6c64d1b1caae27a1e1eac3a743aec078bc652d96

Change-Id: I707fea8100c686ab8232eaf6e4d9a348abdb5236

Change-Id: Idfac26bb0f436799c3431062238e46b1a50d9f14

...which reveals that some uses are not derived from XEventListener, so re-
introduce BaseMutexHelper as an alternative (which originally got superseded by
DisambiguationHelper in 09b546cf "Fix
overloaded-virtual warning in canvas").

Change-Id: I1418370733b72526ec481b70fa69f03e7c28b7ce

Change-Id: Ie01ae7e29f22fbb2f627a9c671f48bb1c19c5f56

Change-Id: I484ef5c4b31122605287b8e1a5f33108f7b22ea2

...which reveals that SpriteCanvasBase is not derived from XBitmapCanvas, so
split up BitmapCanvasBase (just XBitmap) and BitmapCanvasBase2 (plus
XBitmapCanvas) and make IntegerBitmapBase directly abstract over those two as
arguments.

Change-Id: Ieae87fe466bb9f1a861c8a95162ef25235ae5799

Also extend testcase: I made sure that the new version fails without
this fix and without the fix from
48b5b764 as well.

Change-Id: If33aa6d33cdc287620c12b84ad3f50279568bc8d

Change-Id: I527955671e1100f05da717bffe002131baaf0291

the key piece though is that labels that have mnemonic targets
are always candidates for getting mnemonics generated for them

Change-Id: Ie4bcbc18e94467936f40875c749cd22793021d0c

Change-Id: I3b67edd5ba4541a65cb0916abea6db1362c32afd

Change-Id: I7d3bcff12a8f24d4d63851f578f9703bfaa25278

Change-Id: I366539b83c7a93a81fd72f3f2355b09c59f7ae58

Change-Id: Ib304245b6ae64c15cfb6c999580f73e5e228c440

Or, even simpler, don't bother with the needless namespacing.

Change-Id: I4bbb115c1c2c89881a0bf88ccd54b0f5cb8b3518

Change-Id: I1fd2f2f1faa51346eb68445688fb5e1ef85b7124

Project: help  e1e716143a6d6a38fdfa88f9cb72cb258f2be30e

Change-Id: I9613cda8f08ce6a92235b00a053aca4541bba81d

Change-Id: Ifd5c9b16f8f9a42e13f1139076f7616dd3e0f8d0

Project: help  e06c21fee256f13bbb41592da7d1f4a81df6b533

Change-Id: I558cda577595d6807d85bb41ac93500d02d461a6

Change-Id: I25b92686b08137a5292de620d4e348019c21a739

Change-Id: I0ae177349408fd49832056fbc4c300e8e77b2417

Change-Id: Idbfdfe687ac94f1e1135c8a877a7b133056a875f

Change-Id: I27dc7645969e6311bc6c0a3d593924ea41dfdf5d

Change-Id: I8880f0f441456fe1951145551ef6dfa0e9d65b66

Change-Id: Icf620e065e3b15a8d900a6da00fe979cc45c1f07

Change-Id: Ic859f10a4fb70371f7616b4c17bb4c5040fd5051

Change-Id: Icc9dac3f198432f0b548cbe9c559658ee26ba1cc