Age | Commit message (Collapse) | Author |
|
search than Excel.
Some rework for xlookup binary search in rows to get the correct results
when we are searching with binary mode in rows.
Change-Id: I7ef710c4ae638e2cf5d4bee45810cec7057f5d4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166451
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
|
|
This patch changes the usage of type sal_uLong in sc module to sal_Int32.
Looking into ScRefreshTimer constructor in sc/inc/refreshtimer.hxx, it
becomes clear that sal_Int32 is a good choice. The usage is for
communicating the refresh delay, measured in seconds. The reason to use
signed variables is to follow the convention in ScRefreshTimer class.
Change-Id: Ib565fd50ec4e6a46e95e9db06b7798a0b4a38d4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164957
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
and for the duration of Threaded calculation where there will be
no new formats required we can drive number formatting with the
unlocked RO policy.
Change-Id: Ic0e449acdcf834bc569d13b4a984f13c55316801
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165160
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I24c429c7cb8283a384b72499d1c3f4c2f1457c33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162155
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I55c758f6391cecb261adca79ae1b93006bcae806
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155979
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
regression from:
commit a9d6b6ef049dd41c91a30c03df0ba38ba8dcada8
Date: Thu Oct 5 14:12:51 2023 +0100
crash copying text + chart to clipboard with InputOptions::TextWysiwyg
of true, the mxPoolHelper is still null when trying to create a
Printer to use as a reference device
revert that, and use a different simpler workaround for the original
crash case.
Change-Id: I74cec710aec033e1652e637ed056dae1c261aa98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161740
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Reasoning:
+ For clipcontent.cxx, column3.cxx, dbdocutl.cxx, documen8.cxx,formulacell.cxx,
patattr.cxx, stlpool.cxx, table2.cxx, table3.cxx and validat.cxx:
+ sal_uLong variables and functions are being
initialized with/assigned/returning sal_uInt32 or size_t values
+ For column2.cxx:
+ The type of the return values of the `getWeight` function are size_t
+ For document.hxx, documen2.cxx, docsh.hxx, docsh5.cxx, viewfun2.cxx and globstr.hrc
+ `ScDocument::TransferTab`'s return variable's value is constrained to be either 0 or 1; which is better represented as a boolean
Change-Id: If556f7fcc29f7e325618721959ea4e3615b2e755
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154408
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
ScPatternAttr is traditionally derived from SfxPoolItem
(or better: SfxSetItem) and held in the ScDocumentPool
as Item.
This is only because of 'using' the 'poolable'
functionality of the Item/ItemSet/ItemPool mechanism.
Lots of hacks were added to sc and Item/ItemSet/
ItemPool to make that 'work' which shows already that
this relationship is not optimal.
It uses DirectPutItemInPool/DirectRemoveItemFromPool
to do so, also with massive overhead to do that (and
with not much success). The RefCnt in the SfxPoolItem
that is used for this never worked reliably, so the
SfxItemPool was (ab)used as garbage collector (all
Items added and never removed get deleted at last
for good when the Pool goes down). For this reasons
and to be able to further get ItemSets modernized
I changed this. I did two big changes here:
(1) No longer derive ScPatternAttr from SfxItemSet/
SfxSetItem, no longer hold as SfxPoolItem
(2) Add tooling to reliably control the lifetime of
ScPatternAttr instances and ther uniqueness/
reusage for memory reasons
It is now a regular non-derived class. The SfxItemSet
formally derived from SfxSetItem is now a member. The
RefCnt is now also a member (so independent from
size/data type of SfxPoolItem). All in all it's pretty
much the same size as before.
To support handling it I created a CellAttributeHelper
that is at/owned by ScDocument and takes over tooling
to handle the ScPatternAttr. It supports to guarantee
the uniqueness of incarnated ScPatternAttr instances for
a ScDocument by providing helpers like registerAndCheck
and doUnregister. It hosts the default CellAttribute/
ScPatternAttr. That default handling was anyways not
using the standard default-handling of Items/Pools.
I adapted whole SC to use that mainly by replacing calls
to DirectPutItemInPool with registerAndCheck and
DirectRemoveItemFromPool with doUnregister, BUT: This
was not sufficient, the RefCnt kept to be broken.
For that reason I decided to also do (2) in this change:
I added a CellAttributeHolder that owns/regulates the
lifetime of a single ScPatternAttr. Originally it also
contained the CellAttributeHolder, but after some
thoughts I decided that this is not needed - if there
is no ScPatternAttr set, no CellAttributeHolder is
needed for safe cleanup at destruction of the helper.
So I moved/added the CellAttributeHolder to ScPatternAttr
where it belongs more naturally anyways. The big plus is
that CellAttributeHolder is just one ptr, so not bigger
than having a simple ScPatternAttr*. That way, e.g.
ScAttrEntry in ScAttrArray did not 'grow' at all. In
principle all places where a ScPatternAttr* is used can
now be replaced by using a CellAttributeHolder, except
for construction. It is capable to be initialized with
either ScPatternAttr instances from the heap (it creates
a copy that then gets RefCounted) or allocated (it
supports ownership change at construction time).
Note that ScAttrEntry started to get more a C++ class
in that change, it has a constructor. I did not change
the SCROW member, but that should also be done.
Also made registerAndCheck/doUnregister private in
CellAttributeHelper and exclusively used by
CellAttributeHolder. That way the RefCnt works, and a
lot of code gets much simpler (check ScItemPoolCache,
it's now straightforward) and safer and ~ScPatternAttr()
uses now a hard
assert(!isRegistered());
which shows that RefCnt works now (the 1st time?).
There can be done more (see ToDo section below) but I
myself will concentrate on getting ItemSets forward.
This decoupling makes both involved mechanisms more safe,
less complex and more stable. It also opens up
possibilities to further optimize ScPatternAttr in SC
without further hacking Item/ItemSet/ItemPool stuff.
NOTE: ScPatternAttr *should* be renamed to 'CellAttribute'
which describes what it is. The experiencd devs may know
what it does, but it is a hindrance for understanding for
attacting new devs. I already used now names like
CellAttributeHelper/CellAttributeHolder etc., but
abstained from renaming ScPatternAttr, see ToDo list below.
SfxItemSet discussion:
ScPatternAttr still contains a SfxItemSet, or better, a
SfxSetItem. For that reason it still depends on access to
an SfxItemPool (so there is acces in CellAttributeHelper).
This is in principle not needed - no Item (in the range
[ATTR_PATTERN_START .. ATTR_PATTERN_END]) needs that.
In principle ScPatternAttr could now do it's own handling
of those needed Items, however this might be done (linear
array, hash-by-WhichID, ...). The Items get translated
to and from this to the rest of the office anyways.
Note that *merging* of SfxItemSets is *still* needed what
means to have WhichID slots in SfxItemState::DONTCARE,
see note in ScPatternAttr::ScPatternAttr about that. And
there is also the Surrogates stuff which would have to be
checked.
The other extreme is to use SfxItemSet *more*, e.g. directly
derive from SfxItemSet what would make stuff easier, maybe
even get back to using the 'regular' Items like all office,
I doubt that that would be much slower, so why...?
Also possible is to remove that range of Items exclusively
used by ScPatternAttr from ScDocumentPool *completely* and
create an own Pool for them, owned by CellAttributeHelper.
That Pool might even be static global, so all SC Docs could
share all those Items - maybe even the ScPatternAttr
themselves (except the default per document). That would
remove the dependency of ScPatternAttr from a Pool
completely.
ToDo-List:
- rename ScPatternAttr to CellAttribute or similar
- use SfxItemSetFixed with range [ATTR_PATTERN_START
.. ATTR_PATTERN_END] instead of regular SfxItemSet
(if the copy-construtor works now...?)
- maybe create own/separate Pool for exclusive Items
- make ScAttrEntry more a C++ class by moving SCROW
to the private section, add get/set methods and
adapt SC
Had to add some more usages of CellAttributeHolder
to the SC Sort mechanism, there were situations where
the sorted ScPatternAttr were replaced in the Table,
but the 'sorted' ones were just ScPatternAttr*, thus
deleting the valid ones in the Table already. Using
CellAttributeHolder makes this safe, too.
Added a small, one-entry cache to CellAttributeHelper
to buffer the last found buffered ScPattrnAttr. It
has a HitRate of ca. 5-6% and brings the UnitTest
testSheetCellRangeProperties from 0m48,710s to
0m37,556s. Not too massive, but erery bit counts :-)
Also shows that after that change optimizations in
the now split functionality is possible and easy.
Change-Id: I268a7b2a943ce5ddfe3c75b5e648c0f6b0cedb85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161244
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
If the filter background color is selected,
the automatic selection area should include,
the attribute of background cell color too.
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I341c602247e7f71e3c9665e1b594177d8f5553b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158991
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 768433f07873eb608837630f85e7e1b375239fca)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159238
Tested-by: Jenkins
|
|
Add menu options that open a dialog that can add conditional formatting
in a cell range with common options.
Change-Id: Ia54baba08e4b78c4c6e37fa7bff744af8cf06037
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156831
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
The original fix for tdf#100034 (see commit [1]) consisted of explicitly not exporting to XLSX named ranges that are not built-in. This has a side-effect that user-defined named ranges associated with sheets are also not exported to XLSX. Hence, if the user creates a named range linked to a sheet and saves the file to XLSX, the named range is not exported (which is the issue reported in tdf#157318).
This patch implements a new fix for tdf#100034, reverting the previous
fix. When the Print Ranges are cleared by the user, the associated named
ranges are also cleared, thus fixing the original problem.
This new fix has the advantage that user-defined named ranges linked to sheets are again exported to XLSX files.
Regression from commit 639519dc2bad058197b6ff73c9e3df622f979f97
"tdf#100034: Fix to persistently remove print-range".
References:
[1] 639519dc2bad058197b6ff73c9e3df622f979f97
Change-Id: Ic3b84365a6086e96f60b222cd6337991ac90f483
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157455
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
of true, the mxPoolHelper is still null when trying to create a
Printer to use as a reference device
#3 0x00007f6d5e81ee6e in ScDocShell::GetRefDevice (this=this@entry=0x4697e6e0) at libreoffice/sc/source/ui/docshell/docsh3.cxx:471
#4 0x00007f6d5e823439 in ScDocShell::UpdateFontList (this=this@entry=0x4697e6e0) at libreoffice/sc/source/ui/docshell/docsh3.cxx:462
#5 0x00007f6d5e81dd6c in ScDocShell::InitItems (this=this@entry=0x4697e6e0) at libreoffice/sc/source/ui/docshell/docsh2.cxx:98
#6 0x00007f6d5e81e80b in ScDocShell::InitNew (this=0x4697e6e0, xStor=...) at libreoffice/sc/source/ui/docshell/docsh2.cxx:83
#7 0x00007f6d6e2ce99d in SfxObjectShell::DoInitNew (this=this@entry=0x4697e6e0) at libreoffice/sfx2/source/doc/objstor.cxx:470
#8 0x00007f6d5e768daf in ScTransferObj::SetDrawClipDoc (bAnyOle=<optimized out>, pDoc=std::shared_ptr<ScDocument> (use count 2, weak count 0) = {...})
at libreoffice/sc/source/ui/app/transobj.cxx:821
#9 0x00007f6d5ec4735a in ScViewFunc::CopyToClipSingleRange (this=0x37a257a0, pClipDoc=<optimized out>, rRanges=..., bCut=<optimized out>, bIncludeObjects=<optimized out>)
at libreoffice/sc/source/ui/view/viewfun3.cxx:248
#10 0x00007f6d5ec48ab0 in ScViewFunc::CopyToClip (this=this@entry=0x37a257a0, pClipDoc=pClipDoc@entry=0x0, rRanges=..., bCut=bCut@entry=false, bApi=bApi@entry=false,
bIncludeObjects=bIncludeObjects@entry=true, bStopEdit=true) at libreoffice/sc/source/ui/view/viewfun3.cxx:212
#11 0x00007f6d5ec48dc3 in ScViewFunc::CopyToClip (this=this@entry=0x37a257a0, pClipDoc=pClipDoc@entry=0x0, bCut=bCut@entry=false, bApi=bApi@entry=false,
bIncludeObjects=bIncludeObjects@entry=true, bStopEdit=bStopEdit@entry=true) at libreoffice/sc/source/ui/view/viewfun3.cxx:178
#12 0x00007f6d5eb0eada in ScCellShell::ExecuteEdit (this=0x35c3d240, rReq=...) at libreoffice/sc/source/ui/view/cellsh1.cxx:1369
Change-Id: I1eb90a0190719a0ffe52dcdc5b0d87f5198cd5a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157594
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
instead of using SfxObjectShell and then static_cast'ing it
everywhere.
Change-Id: Id3184e44f048228dc4d0d9fa5d579e663c2762cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156945
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When xlsx spreadsheet was opened in LOK on
every save default column width was decreased.
This doesn't happen in non-LOK case.
Column width in Excel are defined by double value
which specifies number of '0' characters which fit
into the column.
On export we use mnCharWidth from XclRootData to
convert Calc twips size to number of characters.
In LOK case it was 102 while in non-lok case 101.
It was caused by different Reference Device used in
ScDocument::GetRefDevice() because in LOK case we
are in WYSWIG mode as introduced in
ScModelObj::initializeForTiledRendering in commit c25062f:
sc tiled rendering: Don't adjust the text width according to printer.
Let's use for export purpose the GetVirtualDevice_100th_mm()
Change-Id: I6709194d7924e8c7e0aaa75ff3901afbcc1f8c11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156576
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 29f72210e92e0152d52b3a1d0253fbb5d8e2dead)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156604
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
it may have left a cell the original range needed in a dirty state,
leading to an assert when the threaded calculation is attempted which
would not have happened if the attempt to expand the range wasn't
attempted.
seen in crashtesting example: forum-mso-en4-784502.xlsx
to reproduce this, load sample document
after it has loaded:
(gdb) break column4.cxx:1946
(gdb) break column4.cxx:1966
data, recalculate, recalculate hard,
the first time breakpoint #1 gets hit:
at column4.cxx:1946 NeedsInterpret is true, so cell
{nRow = 1, nCol = 0, nTab = 3 } was dirty and is set
not-dirty by Interpret. mxGroup->mbPartOfCycle is false
so this returns successfully to allow threading.
the bt to there was:
#0 lcl_EvalDirty(mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>&, int, int, ScDocument&, boost::intrusive_ptr<ScFormulaCellGroup> const&, bool, bool, bool&, bool&)
(rCells=..., nRow1=1, nRow2=4, rDoc=..., mxGroup=..., bThreadingDepEval=true, bSkipRunning=false, bIsDirty=@0x7fffffff4a16: true, bAllowThreading=@0x7fffffff4a17: true)
at sc/source/core/data/column4.cxx:1963
#1 0x00007fff9eef70d1 in ScColumn::HandleRefArrayForParallelism(int, int, boost::intrusive_ptr<ScFormulaCellGroup> const&) (this=0x15ee480, nRow1=1, nRow2=4, mxGroup=...)
at sc/source/core/data/column4.cxx:2012
#2 0x00007fff9f44448a in ScTable::HandleRefArrayForParallelism(short, int, int, boost::intrusive_ptr<ScFormulaCellGroup> const&)
(this=0x1eebda0, nCol=0, nRow1=1, nRow2=4, mxGroup=...) at sc/source/core/data/table1.cxx:2567
#3 0x00007fff9f06b691 in ScDocument::HandleRefArrayForParallelism(ScAddress const&, int, boost::intrusive_ptr<ScFormulaCellGroup> const&)
(this=0x1ba9a40, rPos=..., nLength=4, mxGroup=...) at sc/source/core/data/document.cxx:1792
#4 0x00007fff9f3018f7 in (anonymous namespace)::ScDependantsCalculator::DoIt() (this=0x7fffffff4eb8) at sc/source/core/data/formulacell.cxx:4585
#5 0x00007fff9f30085a in ScFormulaCell::CheckComputeDependencies(sc::FormulaLogger::GroupScope&, bool, int, int, bool)
(this=0x2142cf0, rScope=..., fromFirstRow=false, nStartOffset=0, nEndOffset=3, bCalcDependencyOnly=false) at sc/source/core/data/formulacell.cxx:4720
#6 0x00007fff9f2ff392 in ScFormulaCell::InterpretFormulaGroupThreading(sc::FormulaLogger::GroupScope&, bool&, bool&, int, int)
(this=0x2142cf0, aScope=..., bDependencyComputed=@0x7fffffff56d7: false, bDependencyCheckFailed=@0x7fffffff56d6: false, nStartOffset=0, nEndOffset=3)
at sc/source/core/data/formulacell.cxx:4829
so the CheckComputeDependencies at the start of
ScFormulaCell::InterpretFormulaGroupThreading is successful for aPos of
{nRow = 1, nCol = 1, nTab = 3 } and the cell is not dirty at that point
*however* in the following loop of
for (SCCOL nCurrCol = nColStart; nCurrCol <= nColEnd; ++nCurrCol)
in InterpretFormulaGroupThreading, CheckComputeDependencies for
column 3 is called and the breakpoint #2 is hit, in this case
mxGroup->mbPartOfCycle is true and the {nRow = 1, nCol = 0, nTab = 3 }
cell is set dirty again.
so later during the threaded calculation the cell is found dirty and the
ScFormulaCell::MaybeInterpret() asserts that
!rDocument.IsThreadedGroupCalcInProgress()
Change-Id: I40385f5e8240680c220249dd2966b196efaf5e0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155463
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Remove the duplicated table validity checks and replace them with
FetchTable(..) call, which returns nullptr if the table is not
valid and available, or the table itself. This simpifies the code
all around.
When only the check if the table is available is needed, use
HasTable(..) in those cases.
The call TableExists(..) is identical to HasTable(..) and has been
removed.
Finally use GetTableCount(), which return a SCTAB type for the number
of tables is used instead of static_cast<SCTAB>(maTabs.size())
that was used all over the code.
Change-Id: Ibfd9777b1350ba8e0cbe577783db81589f95591c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154225
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This patch is a pre-requisite for a follow-up patch
which will run SetOptimalRowHeight on all un-sized rows
on FILEOPEN.
XLSX sheets can provide a default height for all rows on that sheet.
That imported/round-tripped well.
However, if Calc optimizes these rows, the undefined rows likely
will change height - since the default XLSX row height tends to be
300 twips, while Calc uses 256 (in ScGlobal::nStdRowHeight).
This patch allows a sheet to define its optimal row height,
so that running .uno:SetOptimalRowHeight doesn't change
any row heights, and doesn't cause all kinds of new row definitions.
make CppunitTest_sc_subsequent_filters_test2 \
CPPUNIT_TEST_NAME=testTdf123026_optimalRowHeight
Change-Id: I35008107d71f66375c7e9469e559f3836cf14df5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152909
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Change-Id: Ief95f111350808f010539bb733a553007d30a9df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152006
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Fixing the crashtesting assert/crash after the original change.
Also a little clean-up.
Change-Id: I35453fbc55b3d5d4064179e84755334c2d3a01ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149583
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
This patch implements the mechanism to save solver settings in LO Calc as well as export/import them from XLSX files.
In MS Excel solver settings are saved as hidden named ranges, so in this patch I used the same strategy to save solver settings in Calc, i.e. by creating named ranges to store the solver settings using the same terminology used in Excel.
With this we gain the ability to save solver settings by tab, as well as export/import since we already have "named ranges/expressions" import/export implemented in LO.
Change-Id: Id41bca261dc3cd8e6888643f0ed6a97b26097876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148112
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Nowadays SfxItemPool_Impl::mpSecondary is ref counted, so
there is no fear in destroying the draw layer before the doc
pool.
This kind of change is needed for drawing styles, as their
item set references the SdrItemPool with a raw pointer, but
they are destroyed as part of the styles pool, much later
than the draw layer.
Change-Id: I169bbacfbdbec2121217b13293b6f495898fe2e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149090
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Dropdown form control size was increased by the size of hidden
rows or columns.
Regression from commit: 1f0b3c7a40edfa81bbc7a58d123a6a2dfd83e4ca
(Improve 'resize with cell' handling)
Change-Id: Ic903a488cab22286f95cfdf4ee559013fd7bfa02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148738
Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
... and use it in one unit test case. Also, remove the code inside
DEBUG_AREA_BROADCASTER macro since it no longer builds & has been
superceded by this new state query method.
Change-Id: I38691a76df5c63034ff488522936dd566bf8b4e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148079
Tested-by: Kohei Yoshida <kohei@libreoffice.org>
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
... then have them start listening again after the copy from
clipboard is complete. Note that in case the pasted cells
are formula cells, those will be handled together as well.
Change-Id: Ia4be814b888734267a39f7c89435011968570b7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147940
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
... by setting the result value or if necessary recalculating even if
AutoCalc is turned off for the document. Similar for other implicitly
recalculating formula types.
Also set a boolean number format if none.
Change-Id: I2f75735707180eccf4b2c525738ac0b763901230
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147425
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I51c1244406e30f5a3893eac42aed65fc92ab1d38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143805
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
need to move it, because modules "below" vcl want
to use the debug output method
Change-Id: Ibcaf4089a1e0b3fcc0b5189c7ebf1aae90f50b48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This requires 2 fixes
(*) First, we are deleting from the front of a block in the mdds
storage, so apply a similar patch to mdds to the previous improvement,
(*) Then, we end up with an O(n^2) situation in ScRangesList::Join.
But we are only displaying this data, and in fact, we only display the
first 1000 ranges anyway, so just clamp the list to 1000 entries, and
pass a flag up to the dialog so that we can report that we stopped
counting.
(*) I had to tweak the testSharedStringPool unit test, since
we are not actually clearing the underlying mdds storage, the
reference counts do not drop until we have removed all the
elements in that block of mdds storage (because then the entire
block is destructed, including the not-yet destructed elements)
Change-Id: I2c998f81dfb46453a48fce1254fd253d299d12b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139400
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
map is already a node based data structure, so the values will stay
in the same place in memory
Change-Id: I774368091ace3775d9d63b3ed561e323ad3adb9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139236
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
we are already using sal_uInt32 in various places, and passing
this through SfxUInt32Item
Change-Id: Iea06b59edc56632b823729462516a6b5fb74e28a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138917
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ScFormulaCell::Interpret() tries to interpret the whole formula group
(or the given range of it), but it's not guaranteed, and possibly
just the called cell will be interpreted. So if a specific range
really needs to be interpreted, handle that case.
Change-Id: I7fb563ae471eefd49e5bb6c92b6aff98c42a440e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138741
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This commit follows the same pattern as
commit c72e500ccaf0ce2261c5233b80fba9342778f810
sw: allow undo of typing in 2 views independent from each other
with some changes since calc and writer have different undo/redo
infrastructure on top of SfxUndoManager.
Change-Id: Ib6e7e21caccb94752c01c529b5013553dba8b4f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The import of pivot tables in xlsx triggers recalculations, even
though it's not necessary. Fixing that properly seems complex given
how ScDPObject is designed, so at least ensure the calculation is
efficient (formula grouping is otherwise done only after pivot
table import). This can especially noticeable for formulas where
groups make a big difference (e.g. COUNTIFS uses ScSortedRangeCache
only for formula groups).
Change-Id: I8dbdf854880707a9707cdc9dc3d73fc1d6b6b000
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136362
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Revert the offending commit
commit feec8e3c34e08b621098a17f1011dccd0b4f7f4c
reduce iteration in ScViewData::GetScrPos
Change-Id: Id1df2bf7f87e6b800b40871c1472ed466b7eb6a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136442
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's the same data for all threads, they access it as read-only,
so it doesn't make sense for each thread to build its own copy.
Change-Id: Ia1559c61d976bcce78661cae7e030bb8430aed7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135794
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
it's a very small object, and trivially movable. No need to allocate it
separately
Change-Id: I0adf947433e73a425f39004297c450a93ac4e5f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135216
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Instead of simply asserting that something failed, say which part
of the .fods test document failed.
Change-Id: Idd901186f27d2395b9e3561fbac6bfc1340b7e72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134460
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
==143282== Invalid read of size 2
==143282== at 0x190CDBFC: SfxItemSet::Count() const (itemset.hxx:96)
==143282== by 0x1910F33E: SfxItemSet::Get(unsigned short, bool) const (itemset.cxx:748)
==143282== by 0x1F14D76C: ScPatternAttr::GetItem(unsigned short, SfxItemSet const&, SfxItemSet const*) (patattr.cxx:1347)
==143282== by 0x1F14D7DA: ScPatternAttr::GetItem(unsigned short, SfxItemSet const*) const (patattr.cxx:1352)
==143282== by 0x202A3E44: ScLineBreakCell const& ScPatternAttr::GetItem<ScLineBreakCell>(TypedWhichId<ScLineBreakCell>, SfxItemSet const*) const (patattr.hxx:83)
==143282== by 0x2028E8BC: ScOutputData::LayoutStrings(bool, bool, ScAddress const&) (output2.cxx:1677)
==143282== by 0x2028D4A8: ScOutputData::DrawStrings(bool) (output2.cxx:1473)
==143282== by 0x202D9879: ScPrintFunc::PrintArea(short, int, short, int, long, long, bool, bool, bool, bool) (printfun.cxx:1675)
==143282== by 0x202DD459: ScPrintFunc::PrintPage(long, short, int, short, int, bool, ScPreviewLocationData*) (printfun.cxx:2301)
==143282== by 0x202DF491: ScPrintFunc::DoPrint(MultiSelection const&, long, long, bool, ScPreviewLocationData*) (printfun.cxx:2713)
==143282== by 0x20031888: ScModelObj::render(int, com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (docuno.cxx:2259)
==143282== by 0x30C1A485: PDFExport::ExportSelection(vcl::PDFWriter&, com::sun::star::uno::Reference<com::sun::star::view::XRenderable> const&, com::sun::star::uno::Any const&, StringRangeEnumerator const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, int) (pdfexport.cxx:219)
==143282== by 0x30C1F879: PDFExport::Export(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (pdfexport.cxx:987)
==143282== by 0x30C33BA2: PDFFilter::implExport(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (pdffilter.cxx:174)
==143282== by 0x30C33F2A: PDFFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (pdffilter.cxx:237)
==143282== by 0x21AC6986: SfxObjectShell::ExportTo(SfxMedium&) (objstor.cxx:2488)
==143282== by 0x21AC2363: SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) (objstor.cxx:1553)
==143282== by 0x21ACE816: SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString const&, rtl::OUString const&, SfxItemSet const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (objstor.cxx:2966)
==143282== by 0x21ACCA87: SfxObjectShell::CommonSaveAs_Impl(INetURLObject const&, rtl::OUString const&, SfxItemSet&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (objstor.cxx:2756)
==143282== by 0x21AA8CDB: SfxObjectShell::APISaveAs_Impl(rtl::OUString const&, SfxItemSet&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (objserv.cxx:317)
==143282== by 0x21B2B4AD: SfxBaseModel::impl_store(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, bool) (sfxbasemodel.cxx:3132)
==143282== by 0x21B2CB12: SfxBaseModel::storeToURL(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (sfxbasemodel.cxx:1768)
==143282== by 0x1C507AFE: ScPDFExportTest::exportToPDF(com::sun::star::uno::Reference<com::sun::star::frame::XModel> const&, ScRange const&) (scpdfexport.cxx:192)
==143282== by 0x1C511A33: ScPDFExportTest::testForcepoint97() (scpdfexport.cxx:571)
==143282== by 0x1C52778D: void std::__invoke_impl<void, void (ScPDFExportTest::*&)(), ScPDFExportTest*&>(std::__invoke_memfun_deref, void (ScPDFExportTest::*&)(), ScPDFExportTest*&) (invoke.h:74)
==143282== by 0x1C5276C1: std::__invoke_result<void (ScPDFExportTest::*&)(), ScPDFExportTest*&>::type std::__invoke<void (ScPDFExportTest::*&)(), ScPDFExportTest*&>(void (ScPDFExportTest::*&)(), ScPDFExportTest*&) (invoke.h:96)
==143282== by 0x1C527659: void std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420)
==143282== by 0x1C5275E2: void std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>::operator()<, void>() (functional:503)
==143282== by 0x1C52758C: void std::__invoke_impl<void, std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&>(std::__invoke_other, std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&) (invoke.h:61)
==143282== by 0x1C52753C: std::enable_if<is_invocable_r_v<void, std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&>, void>::type std::__invoke_r<void, std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&>(std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&) (invoke.h:111)
==143282== by 0x1C52731C: std::_Function_handler<void (), std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()> >::_M_invoke(std::_Any_data const&) (std_function.h:290)
==143282== by 0x1C527A34: std::function<void ()>::operator()() const (std_function.h:590)
==143282== by 0x1C527078: CppUnit::TestCaller<ScPDFExportTest>::runTest() (TestCaller.h:175)
==143282== by 0x49326F2: CppUnit::TestCaseMethodFunctor::operator()() const (TestCase.cpp:32)
==143282== by 0x15937E3D: (anonymous namespace)::Protector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (vclbootstrapprotector.cxx:46)
==143282== by 0x4929ED1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20)
==143282== by 0x4B05D6D: (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (unobootstrapprotector.cxx:78)
==143282== by 0x4929ED1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20)
==143282== by 0x4AF2F2A: (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (unoexceptionprotector.cxx:62)
==143282== by 0x4929ED1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20)
==143282== by 0x491261E: CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (DefaultProtector.cpp:15)
==143282== by 0x4929ED1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20)
==143282== by 0x4928690: CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (ProtectorChain.cpp:86)
==143282== by 0x4946ACD: CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (TestResult.cpp:182)
==143282== by 0x4932103: CppUnit::TestCase::run(CppUnit::TestResult*) (TestCase.cpp:91)
==143282== by 0x4932BCF: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64)
==143282== by 0x4932A5F: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23)
==143282== by 0x4932BCF: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64)
==143282== by 0x4932A5F: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23)
==143282== by 0x494FDBF: CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) (TestRunner.cpp:47)
==143282== Address 0x1d7624b0 is 64 bytes inside a block of size 120 free'd
==143282== at 0x4847669: operator delete(void*) (vg_replace_malloc.c:923)
==143282== by 0x1F150EA1: ScPatternAttr::~ScPatternAttr() (patattr.hxx:53)
==143282== by 0x190D29B2: SfxItemPool::Remove(SfxPoolItem const&) (itempool.cxx:802)
==143282== by 0x1EA27F8E: ScAttrArray::SetPatternAreaImpl(int, int, ScPatternAttr const*, bool, ScEditDataArray*, bool) (attarray.cxx:574)
==143282== by 0x1EBF43D5: ScAttrArray::SetPattern(int, ScPatternAttr const*, bool) (attarray.hxx:148)
==143282== by 0x1EBD9068: ScColumn::ApplyAttr(int, SfxPoolItem const&) (column.cxx:634)
==143282== by 0x1EC6C1EB: ScColumn::SetNumberFormat(int, unsigned int) (column2.cxx:3094)
==143282== by 0x1F1CB737: ScTable::SetNumberFormat(short, int, unsigned int) (table2.cxx:2238)
==143282== by 0x1EE3F135: ScDocument::SetNumberFormat(ScAddress const&, unsigned int) (document.cxx:3717)
==143282== by 0x1F09CCA5: ScFormulaCell::InterpretTail(ScInterpreterContext&, ScFormulaCell::ScInterpretTailParameter) (formulacell.cxx:2155)
==143282== by 0x1F099D9F: ScFormulaCell::Interpret(int, int) (formulacell.cxx:1615)
==143282== by 0x1ECC048D: ScFormulaCell::MaybeInterpret() (formulacell.hxx:465)
==143282== by 0x1F09F5C8: ScFormulaCell::IsValue() (formulacell.cxx:2760)
==143282== by 0x1EA82355: (anonymous namespace)::hasNumericImpl(CellType, ScFormulaCell*) (cellvalue.cxx:155)
==143282== by 0x1EA822FA: ScRefCellValue::hasNumeric() const (cellvalue.cxx:624)
==143282== by 0x2028E876: ScOutputData::LayoutStrings(bool, bool, ScAddress const&) (output2.cxx:1676)
==143282== by 0x2028D4A8: ScOutputData::DrawStrings(bool) (output2.cxx:1473)
==143282== by 0x202D9879: ScPrintFunc::PrintArea(short, int, short, int, long, long, bool, bool, bool, bool) (printfun.cxx:1675)
==143282== by 0x202DD459: ScPrintFunc::PrintPage(long, short, int, short, int, bool, ScPreviewLocationData*) (printfun.cxx:2301)
==143282== by 0x202DF491: ScPrintFunc::DoPrint(MultiSelection const&, long, long, bool, ScPreviewLocationData*) (printfun.cxx:2713)
==143282== by 0x20031888: ScModelObj::render(int, com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (docuno.cxx:2259)
==143282== by 0x30C1A485: PDFExport::ExportSelection(vcl::PDFWriter&, com::sun::star::uno::Reference<com::sun::star::view::XRenderable> const&, com::sun::star::uno::Any const&, StringRangeEnumerator const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, int) (pdfexport.cxx:219)
Change-Id: Idf19b79f5aef7e07666249f5f9ec510003a3f886
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132431
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ib0a87bae89903f9ae851a6e3e2d6ef9f9197cf13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134360
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
It's unclear what "block" is supposed to mean, as that may mean
"cells with no value", but a cell also may have a note, or since
recently apparently also a sparkline. To make it even more confusing,
there is IsBlockEmpty(), which may explicitly take bIgnoreNotes set
to true, in which case it presumably should check only data, but then
the recent sparklines addition still counts sparklines even in that
case, which is presumably a mistake.
Rename the data-only function to make it clear, and remove the extra
argument from the empty-in-all-ways function.
Change-Id: I8e3f75407d243b733d61640e2f54954762601ab1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134217
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
For better or worse the usual order of arguments in Calc is
SCCOL, SCROW, SCTAB, so make this consistent.
Change-Id: Ie63c75f5ae92f82cb757c0873f7ff569f331e0df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134229
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ifa769e20d91f7899fa81df537a7f3b7aeff52115
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134125
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The idea is that there's a cache for a given range, which keeps
a vector of SCROW items, sorted by values of those cells. This
allows some specific cases of e.g. COUNTIF to simply use
BinarySearch() to find the range that matches and work only with
that. This commit implements using this cache for COUNTIF.
Change-Id: I5b36b289b4aecb3b8245bbb447fbb299371262e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134120
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This moves code related to accessing cells to query to a template
base class. Creating more specialization of that class will allow
queries that use a cache of sort order for the cells.
Change-Id: I47d1bc2d038717ff64f1d11fa6c7dba2359fec11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134096
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
I don't see why it should be private, it's range checked,
so there should be no harm. Especially when a number of classes get
declared as friends to get access to it anyway.
Change-Id: I333d749aa9d09aaf9dcbabf43d67a67d1257a132
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134051
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This is a follow-up to f15e6293cf78d67963a6e512f60a11ae58da72c5.
Change-Id: I3f1e6bbb1fe83fab48a0c3889fb53c6919f6351d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133967
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
ScFillSeriesDlg always expects the strings describing the start and end values
to be in the system locale. This change ensures that and fixes the bug where
using non-locale-default data in the Fill Series dialog leads to an error.
Change-Id: I25eafa2174294dc35a63473a54c529c2d7bd87ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132532
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
d468958331f36310d11265ba55d7c27366ab58ab improved COUNTIF performance
by copy&pasting the generic query iterator and then basically removing
what was not necessary. Which is in general a good way to improve
the performance, except for the copy&paste part, as the code has
already started to diverge (e.g. fc3b904b671a71266db2e8b30cbeeef4f79).
So instead make the shared code into a template and reuse that from
specific code. This has exactly the same performance as the copy&paste
way.
Change-Id: I168319a1f4273bafc8c0742a114dafbf433968bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133324
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
If there's a document with a huge formula group, InterpretDirtyCells()
on load will only interpret the range needed for drawing. But then
scrolling just a bit could result in e.g. IsValue() call on a cell,
and that could result in unrestricted Interpret() on the whole
huge formula group, which could be slow. So explicitly interpret
just the drawn cells in the hope that it'll avoid any further
Interpret() calls.
Change-Id: I01c9f95cf8a1cf240b798feef27d21010957030c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133306
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The function has been there since the initial commit and is not
documented, but I think it counts the shortest amount of empty
cells in the given area starting from the direction given. And
AFAICT the off-by-one error was there since the initial commit,
when it returned one less if the entire area was empty and
the direction was vertical (horizontal was fine). And
ScHTMLExport::FillGraphList() even was adjusted for this until
my recent commit changing that code). But then ad2bc869bfe2d34bde
added a shortcut for unallocated columns that didn't have
the error. And the error even got corrected during the rewrite
in c008dc483f8c6840803983e7e351cec6fdd32070, but then
01de94471c20a8b9c36d6080638d70e57eac55bf reverted that. Anyway,
so fix this, I think all the relevant code should(?) now work
properly.
Change-Id: I194691f7276a1cea75945de05cb0dda2cdca859a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133319
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|