summaryrefslogtreecommitdiff
path: root/sc/inc/document.hxx
AgeCommit message (Collapse)Author
2024-04-30tdf#160725 - Fix XLOOKUP has different result for approximateBalazs Varga
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
2024-04-10tdf#114441 Convert sal_uLong to better integer typesRafał Dobrakowski
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>
2024-03-23Related: tdf#160056 do calc NumberFormatting via ScInterpreterContextCaolán McNamara
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-16loplugin:unusedmethodsNoel Grandin
Change-Id: I24c429c7cb8283a384b72499d1c3f4c2f1457c33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162155 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-01-09tdf#114441 - Convert sal_uLong to better integer typessahil
Change-Id: I55c758f6391cecb261adca79ae1b93006bcae806 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155979 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2024-01-07Resolves: tdf#159046 hang on export of math objects in cellsCaolán McNamara
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>
2024-01-03tdf#114441 Convert use of sal_uLong to better integer typesgilssonn
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>
2023-12-28Decouple ScPatternAttr from SfxItemPoolArmin Le Grand (allotropia)
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-11-11sc: extend backcolor areaHenry Castro
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-27tdf#157930 sc: Add easy to use conditional formatting menuParis Oplopoios
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>
2023-10-09tdf#100034 tdf#157318 XLSX export: fix lost named ranges associated to sheetsRafael Lima
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-10-06crash copying text + chart to clipboard with InputOptions::TextWysiwygCaolán McNamara
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>
2023-09-15reduce casting around ScDocShellNoel Grandin
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>
2023-09-07lok: save to xlsx changes column sizeSzymon Kłos
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>
2023-08-14tdf#156677 if CheckComputeDependencies failed in expanded range...Caolán McNamara
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-07-13sc: remove duplicated table validity checks and other duplicationsTomaž Vajngerl
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>
2023-06-27tdf#123026 sc xlsx: provide per-sheet optimal row height settingJustin Luth
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-05-20loplugin:unusedmethodsNoel Grandin
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>
2023-03-26Related: tdf#154005 sc ods fileopen: fix dropdown form control sizeBalazs Varga
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 Lima
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-19sc drawstyles: Delay the destruction of SdrItemPoolMaxim Monastirsky
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>
2023-03-14tdf#154005 sc ods fileopen: fix dropdown form control sizeBalazs Varga
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>
2023-03-02Add a means to query the internal broadcaster state ...Kohei Yoshida
... 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>
2023-02-28tdf#153669: Track formulas that stopped listening ...Kohei Yoshida
... 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>
2023-02-23Resolves: tdf#153767 Try harder to import OOXML bool shared formula resultEike Rathke
... 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
2022-12-08Related: tdf#120190 Factor out ScDocument::CreateSharedStringTextObject()Eike Rathke
Change-Id: I51c1244406e30f5a3893eac42aed65fc92ab1d38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143805 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-09-14move ErrCode to comphelper and improve debug output stringNoel Grandin
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>
2022-09-05tdf#150749 Find and replace on very large sheetNoel Grandin
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-09-02no need to use unique_ptr for this map in sc::ScRangeNameNoel Grandin
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>
2022-08-27sal_uLong->sal_uInt32 in ValidationEntryNoel Grandin
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>
2022-08-25try harder to ensure InterpretCellsIfNeeded() interprets (tdf#150499)Luboš Luňák
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-07-30sc: allow undo of typing in 2 views independent from each otherNoel Grandin
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>
2022-06-26more efficient recalculations from xlsx import of pivot tablesLuboš Luňák
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>
2022-06-25tdf#149647 LibreOffice Calc cursor not positioned correctlyNoel Grandin
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-16share ScSortedRangeCache between threadsLuboš Luňák
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>
2022-06-01pass ScRange around by valueNoel Grandin
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-17provide more details about failures in Calc 'functions' testsLuboš Luňák
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>
2022-05-16forcepoint#97 avoid Invalid read of size 2Caolán McNamara
==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>
2022-05-16Unfriend someMike Kaganski
Change-Id: Ib0a87bae89903f9ae851a6e3e2d6ef9f9197cf13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134360 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-12IsEmptyBlock() -> IsEmptyData()Luboš Luňák
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-12fix up order of some ScDocument functionsLuboš Luňák
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>
2022-05-11make ScSortedRangeCache work for also ScQueryEntry::ByStringLuboš Luňák
Change-Id: Ifa769e20d91f7899fa81df537a7f3b7aeff52115 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134125 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11introduce Calc cache for sorted handling of unsorted cellsLuboš Luňák
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>
2022-05-10extend ScQueryCellIteratorBase for custom cell accessLuboš Luňák
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-09make ScDocument::FetchTable() publicLuboš Luňák
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>
2022-05-07tdf#107765: Use the correct sheet index.Kohei Yoshida
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>
2022-05-06tdf#148383: Obtain start/end strings always in system localeDaniel Kamil Kozar
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ňák
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ňák
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 an off-by-one error in GetEmptyLinesInBlock()Luboš Luňák
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>