summaryrefslogtreecommitdiff
path: root/sc/inc/table.hxx
AgeCommit message (Collapse)AuthorFilesLines
9 daystdf#114441 Convert sal_uLong to better integer typesRafał Dobrakowski1-3/+4
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>
11 daystdf#160064 Hide named ranges/expressions of solver modelsRafael Lima1-1/+1
Prior to this patch, all named ranges/expressions associated with solver models were visible by default, which clutters the UI with various names in the Manage Names dialog. Now all such named ranges/expressions are hidden by default, thus mimicking what MSO does. Change-Id: I79727b375c48527632c4967d174c61f99ff41050 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165621 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-04-03Remove duplicated includeAndrea Gelmini1-2/+0
Change-Id: I3255d4a4b4435c092def3c5d17eea27c6f59c491 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165706 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-04-02tdf#146619 Remove unused #includes from C/C++ filesRafał Dobrakowski1-0/+2
'sc' module was cleaned. Change-Id: Ia491d741a4c1c5314f35ebb4baa82dd516948ae7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165699 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2024-03-25tdf#126573 Add Excel2021 array function SORT to CalcBalazs Varga1-1/+0
TODO/WIP: oasis proposal More information about how this new function works: https://support.microsoft.com/en-au/office/sort-function-22f63bd0-ccc8-492f-953d-c20e8e44b86c https://exceljet.net/functions/sort-function Note: Move ScSortInfoArray class to sortparam.hxx, which is a more logical place. Change-Id: I70e720e93ba0414d54cb3437de0bfa066508fe30 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164778 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-03-23Related: tdf#160056 do calc NumberFormatting via ScInterpreterContextCaolán McNamara1-1/+1
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>
2024-01-09tdf#114441 - Convert sal_uLong to better integer typessahil1-1/+1
Change-Id: I55c758f6391cecb261adca79ae1b93006bcae806 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155979 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2023-12-30tdf#158254: generalize and use algorithm to apply with allocationMike Kaganski1-0/+35
Commit 17bcf1073bf21088b9845e36fe735622d8f88fd7 (introduce ScColumnData for ScColumn/ScTable code sharing, 2022-05-05) implemented an algorithm to only allocate needed amount of columns, and/or apply to default data when needed. It was done for ApplySelectionCache, ChangeSelectionIndent, ClearSelectionItems. Yet, many other functions need the same approach. This change introduces ScTable::ApplyWithAllocation template, which allows to use this algorithm uniformly to any operation on a selection, which ultimately applies to ScColumnData. The code in the functions mentioned above is replaced with its use; and ApplySelectionStyle is fixed using it. Change-Id: Ic8890d9980fcb01b61bb111183b355c623f866a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161441 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-28Decouple ScPatternAttr from SfxItemPoolArmin Le Grand (allotropia)1-2/+2
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>
2023-12-19tdf#154339: do not cache GetCellArea results for nowXisco Fauli1-8/+1
Partially revert 0a55aa8ba38aea56a2bce1504fd687e510f66b9d "calc: cache GetCellArea results" Change-Id: I371a56f64afe541d9a194e6435fda3fb27bc43ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160349 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-12-12sc: Unify GetColumnDataAron Budea1-8/+2
This added ColumnData: a15c02effa654da06e9695b5e4c0c595f851a878 This added GetColumnData: 1c53f5b6647dcffa57012990d342b21eaff19888 Both functions are the same, one is const, other is non-const. Change-Id: I8ed214290c7ee8d9e22bd466f9ada95b40300e34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160601 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-01move the SfxItemPoolCache to sc/Noel Grandin1-1/+1
and rename it to ScItemPoolCache, since its only use is to handle ScPatternAttr objects Change-Id: I68a2dd5f47fcf902f9df552e1a1767d5061d85d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160162 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-30No kit notification of note position changes on insert/delete rowCaolán McNamara1-0/+1
while there is for insert/delete col. Inserting/Deleting a column will explicitly update comments as part of a bulk operation and block the drawing layer from updating any existing captions before that. A side-effect of this is that the note captions are generated for all comments in the moved cols when this happens. While with a row the drawing layer is allowed update existing caption positions and doesn't generate any new captions. Presumably there's a missed optimization for insert/delete cols to not generate extra captions that didn't exist before the change, but leave that aside for now and add a UpdateNoteCaptions that just notifies of note position changes when rows are inserted/deleted and continue to piggy back on the note caption update for insert/delete cols. Change-Id: I4d76d15aee1de9ea5553e90b2051354bce02b1db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160138 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-11sc: extend backcolor areaHenry Castro1-0/+3
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
2023-10-11tdf#156815 Reset solver settings when a sheet is renamedRafael Lima1-0/+4
When a sheet is renamed, the SolverSettings object needs to be reset so that the updated references of the named ranges are reloaded the next time the Solver dialog is opened. Change-Id: I8d501bb5b52f6a69bc899a62863893744d80dc69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156872 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-10-09tdf#100034 tdf#157318 XLSX export: fix lost named ranges associated to sheetsRafael Lima1-0/+4
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>
2023-08-14tdf#156677 if CheckComputeDependencies failed in expanded range...Caolán McNamara1-1/+2
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>
2023-06-29loplugin:unusedmethodsNoel Grandin1-2/+0
Change-Id: I95ab7581dec35b113cb657ce8e5ee27c89c73593 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153746 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-27tdf#123026 sc xlsx: provide per-sheet optimal row height settingJustin Luth1-0/+11
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>
2023-06-17Resolves: tdf#153517 Use tools::Duration for FillSeries with (date+)timeEike Rathke1-3/+5
Change-Id: I18567fdac512ee786ce4b0785b01b2ae6da7450e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153203 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2023-05-08tdf#95520 Autofilter: Sort by colorSamuel Mehrbrodt1-0/+3
Change-Id: I2c1455cc2c741d16f09eccee0bf489f8990684f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151064 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2023-03-26Related: tdf#154005 sc ods fileopen: fix dropdown form control sizeBalazs Varga1-0/+2
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>
2023-03-25tdf#38948 Save solver settings to fileRafael Lima1-0/+6
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>
2023-03-02Add a means to query the internal broadcaster state ...Kohei Yoshida1-0/+3
... 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>
2022-11-21calc: cache GetCellArea resultsSzymon Kłos1-1/+8
This will avoid repeated lookup in the ScTable::GetCellArea. Which is used for vcl::ITiledRenderable::getDataArea(). Tested in CppunitTest_sc_ucalc Change-Id: Ied58cfe447e1b924af9b401e95e127c784b80355 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142279 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Dennis Francis <dennis.francis@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142995 Tested-by: Jenkins Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
2022-09-29introduce ScTable::GetColumnData() (tdf#151182)Luboš Luňák1-0/+8
This is intended to handle possibly unallocated columns similarly to CreateColumnIfNotExists(), but unlike that one this one does not allocate, if the column is not allocated then the default column data is returned. This is intended for reading of columns. Change-Id: Ic3b637eb3d16bac69ebc7ecd389973407db4f7fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140737 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-09-05tdf#150749 Find and replace on very large sheetNoel Grandin1-2/+2
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>
2022-08-25try harder to ensure InterpretCellsIfNeeded() interprets (tdf#150499)Luboš Luňák1-1/+1
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>
2022-06-25tdf#149647 LibreOffice Calc cursor not positioned correctlyNoel Grandin1-1/+1
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>
2022-06-15tdf#126109 calc slow when replacing string to numberNoel Grandin1-1/+2
retain the column block iterator array during the process, shaves 20% off the time Change-Id: Id492cf142ecc34af6fd236135d87f49b5a630d5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135855 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-10loplugin:constantparamNoel Grandin1-1/+1
Change-Id: I8134744b6c1279c497d4763eddf614bb840f7f3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135602 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-01pass ScRange around by valueNoel Grandin1-6/+6
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>
2022-05-18make CreateColumnIfNotExists() non-constLuboš Luňák1-4/+4
Generally const functions should not modify the data, so this generally should not be needed. Those functions that need to allocate a column because they can't/don't handle default values for non-existent columns well should go with const_cast, being an exception to the rule. Change-Id: I62706da5b447019542d6775f14064fa15b71f3c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134488 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-12IsEmptyBlock() -> IsEmptyData()Luboš Luňák1-2/+3
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>
2022-05-10extend ScQueryCellIteratorBase for custom cell accessLuboš Luňák1-2/+3
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>
2022-05-06tdf#148383: Obtain start/end strings always in system localeDaniel Kamil Kozar1-1/+1
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>
2022-04-22do not duplicate code for ScCountIfCellIteratorLuboš Luňák1-1/+2
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>
2022-04-22try to limit cell interpreting to only visible cells when drawingLuboš Luňák1-0/+1
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>
2022-04-22fix checking whether a block of cells is emptyLuboš Luňák1-0/+1
The GetEmptyLinesInBlock() call has unclear semantics and it appears that it has an off-by-one error. Use a simple clear function for the check. Change-Id: I45d9b73428aedababc1ad93c202daa1de945b5bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133303 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-21rework GetColumnsRange() and ScColumnsRangeLuboš Luňák1-7/+10
The problem with GetColumnsRange() was that it was clamping the range to the number of allocated columns, but that's not always wanted, e.g. ScDocument::InsertMatrixFormula() needs to iterate over the whole range and allocate columns if necessary instead of ignoring them. From an API point of view it's also not very obvious that something called GetColumnsRange() actually does something more than just returning the given range. Handle this by making GetColumnsRange() return the actual given range, and add GetWriteableColumnsRange() and GetAllocatedColumnsRange() for the specific cases. This also required changing ScColumnsRange to work simply on SCCOL value instead of using std::vector iterator (since the vector may not have all the elements in the range). Change-Id: I9b645459461efe6b282e8ac5d7a29549830f46c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133295 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-12don't artificially clamp attribute iterators rangeLuboš Luňák1-4/+0
Even ScDocument::GetDefPattern() can be modified by the user (it's the default style that can be edited), so it's conceptually incorrect to ignore it while iterating, and clamping to allocated columns is also no longer needed. If this makes some code slow, then that needs explicit handling in that code or some other way of speeding things up. Change-Id: I4a7c7fef0a8625b559bbce4580df19a5e9ed92a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132911 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-07sc: take sparklines into account with auto fillTomaž Vajngerl1-0/+1
Change-Id: I6bdb5f4291aece7ec02d8de0731b8f983b4f2bb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132592 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-04-05sc: improve SparklineList to track added SparklineGroupsTomaž Vajngerl1-0/+1
SparklineList used to only track added Sparklines for a sheet, but usually (in an export) we want to start with SparklineGroups and then search for all sparklines belonging to a group. This changes to use that. Now there is a method getSparklineGroups() and then another method getSparklineFor(), which returns all sparklines for the input group. Also added SparklineListTest, and refactored the export code for OOXML and ODF. Change-Id: I975e30f649788d41aab92a9a3220e38998e39670 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132543 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-04-04sc: undo/redo for sparklines when deleting the cell contentTomaž Vajngerl1-0/+1
This adds support for undo/redo when clearing the content of a cell, which includes a sparkline. Change-Id: I79d9ef965e21cf5b35de84aa3b5cb93b644777ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132476 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-04-04sc: change GetSparkline to return a shared_ptr instead of raw ptrTomaž Vajngerl1-1/+1
Change-Id: If3d7b3ad4b96eb7d3b126ee8b130f8d5e684cd3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132472 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-04-03sc: support deleting a Sparkline with 'Clear Content' functionTomaž Vajngerl1-0/+1
Change-Id: Ida61b402170238fb0505c777e49954c15d376cf0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132467 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-03-29sc: refactor sparkline struture to store a list of sparklinesTomaž Vajngerl1-0/+9
We need to access a list of sparklines and sparkline groups for a sheet. To preven going through all the columns of a sheet, we need to store all the created sparklines in a list. For this it is necessary to change the model structrue a bit. A cell now has a container that stores a shared_ptr to the sparkline instead of storing the sparkline directly. With this we can store a list of weak_ptr to the sparklines in a list (vector), which can be accessed at any time and is quite fast. This is needed by the OOXML export. Change-Id: Iaca0a41e20912775f072ea6e8cab9c44367d6f30 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131919 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-03-25fix ScTable::GetLastChangedCol() for unallocated columnsLuboš Luňák1-4/+4
Column flags and widths are stored separately from ScColumn data, and so don't depend on allocated columns count. Also rename the functions from the misleading generic name to what they actually do. Change-Id: If85ae80efda1d8b382fa3b559aa65be0292e25ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132114 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-23loplugin:unusedmethodsNoel Grandin1-2/+0
Change-Id: I59c9e52997e80174a3aa7f81bacdfb29e47be0a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131952 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-21ScColumnsRange::Iterator actual needs to be bidirectionalStephan Bergmann1-1/+1
...since 1463625ae26900d2461fd72a5a2c894b9f1b8726 "dynamic column container: fix some more for loops" started to use it with std::reverse_iterator (but apparently forgot to update the iterator_category, causing > In file included from sc/source/core/data/column.cxx:20: > In file included from sc/inc/column.hxx:22: > In file included from sc/inc/global.hxx:22: > In file included from sc/inc/address.hxx:22: > In file included from include/rtl/ustrbuf.hxx:35: > In file included from ~/llvm/inst/bin/../include/c++/v1/string_view:206: > In file included from ~/llvm/inst/bin/../include/c++/v1/__string:13: > In file included from ~/llvm/inst/bin/../include/c++/v1/__algorithm/copy.h:12: > In file included from ~/llvm/inst/bin/../include/c++/v1/__algorithm/unwrap_iter.h:14: > In file included from ~/llvm/inst/bin/../include/c++/v1/iterator:669: > In file included from ~/llvm/inst/bin/../include/c++/v1/__iterator/reverse_access.h:14: > ~/llvm/inst/bin/../include/c++/v1/__iterator/reverse_iterator.h:53:5: error: static_assert failed due to requirement '__is_cpp17_bidirectional_iterator<ScColumnsRange::Iterator>::value || bidirectional_iterator<ScColumnsRange::Iterator>' "reverse_iterator<It> requires It to be a bidirectional iterator." > static_assert(__is_cpp17_bidirectional_iterator<_Iter>::value || bidirectional_iterator<_Iter>, > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > sc/inc/table.hxx:146:37: note: in instantiation of template class 'std::reverse_iterator<ScColumnsRange::Iterator>' requested here > std::reverse_iterator<Iterator> rbegin() { return std::reverse_iterator<Iterator>(maEnd); } > ^ etc.) Change-Id: Ice7527412a379a5ecb655349386e8814c911e87e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131909 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-19 20:26:59 +0000