summaryrefslogtreecommitdiff
path: root/sc/inc/document.hxx
AgeCommit message (Collapse)Author
2020-04-08Resolves: tdf#131442 Sort must not contain matrix formula except 1x1 arrayEike Rathke
Change-Id: Idc7a9646a70c59fceee0b36426f38a938cf073ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91858 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-03-12Revert "loplugin:constfields in sc"Noel Grandin
This reverts commit fb1d3b580763a333bbbfe115d09e1b5cd8849675. Now that we know that making fields has negative side effects like disabling assignment operator generation. Change-Id: Ib48334ffbeb2c768896dd8ced6818aa0b9910b0b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90333 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-14sc: rowcol: convert mark dataNoel Grandin
with this patch I can finally load a 3201 column document Change-Id: I880d485b3f628836e7aed92c276e660466a3b19c Reviewed-on: https://gerrit.libreoffice.org/85139 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-13sc: rowcol: tdf#50916 create ScSheetLimits to hold by rtl::ReferenceNoel Grandin
ScTokenArray sometimes outlives the ScDocument that created it, which means it accesses dead data when it tries to validate columns and rows. So create the ScSheetLimits class, which ScTokenArray can hold by reference counted pointer. Change-Id: Ic5771734fe4962d12f024fc1b29232124c14208a Reviewed-on: https://gerrit.libreoffice.org/85117 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2019-12-11sc: rowcol: tdf#50916 initial conversion of Valid* methodsNoel Grandin
just default the params for now Change-Id: I13ee78aeaa1133a167d57520b334d5e644e28ece Reviewed-on: https://gerrit.libreoffice.org/84926 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-20tdf#128812 speed up loading calc doc with lots of countifNoel Grandin
by creating a copy of ScQueryCellIterator that is specialised for this use-case. Takes the opening time from 50s to 8s on my machine. Change-Id: I193a7c181a5dfed6fecf75e871729d73625d0df6 Reviewed-on: https://gerrit.libreoffice.org/83299 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-15reduce iteration in ScViewData::GetScrPosNoel Grandin
we already have a ScTable::GetRowHeightScaled method that uses spans, so use that. Change-Id: I126292b4a8b37ebf2d4f737dcbfdadc31226531e Reviewed-on: https://gerrit.libreoffice.org/82520 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-12Resolves: tdf#122232 Move TabStartCol logic to ScTable::GetNextPos()Eike Rathke
... instead of blindly applying it to every move if set. Change-Id: Ief2efb4eb2288cd479852d5a250c2523715de38b Reviewed-on: https://gerrit.libreoffice.org/82513 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2019-10-24sc: rowcol: tdf#50916 convert documen*Noel Grandin
Change-Id: I101ff537181058500d240c44114bfefedc03aee4 Reviewed-on: https://gerrit.libreoffice.org/81429 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-17Reuse pre-allocated ScInterpreter for HandleStuffAfterParallelCalculationDennis Francis
Change-Id: Idf10bb214d6d82370512eeb39ba7786dd9bceb38 Reviewed-on: https://gerrit.libreoffice.org/80846 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-09sc: rowcol: store sheet maximum sizes in ScDocument.Michael Meeks
For now, hard coded to MAXCOL, MAXROW while we re-factor. Change-Id: I5e1aafc91ba1434a9a248d33bf0da4f4a2dc3a1b Reviewed-on: https://gerrit.libreoffice.org/80434 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: Eike Rathke <erack@redhat.com>
2019-10-01Thread a group of formula-groups together if possibleDennis Francis
Just before about to thread a FG, look to left and right for "mutually" independent FG's with some restrictions and thread this group of FG's together treating it as a single but longer computation load. For now the restrictions are :- All formula-groups in a FG "group" must have :- 1. Same length 2. Same relative position. 3. Same weight. This is very helpful in cases similar to the below : There are lots of (say 32) consecutive formula-groups all with same "small" length (say 8) and same weight. By conventional formula-group-threading the speed-up is limited to 8x even if we have a 256 core processor, but with this threading-multiple-formula-groups patch (in this case) we can get a speed-up of 256x provided we have a >= 256 core machine. So effectively with this patch the speed-up is now only limited to the number of cells in a range consisting of mutually indepdendent formula-groups rather than number of cells in each formula-group. Change-Id: Ib25b5abbb583fa207e8befff9a908d14313f3d51 Reviewed-on: https://gerrit.libreoffice.org/79485 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-09-26loplugin:constmethod in scNoel Grandin
Change-Id: I78c4fb4acf21756f91582caee5e30e3ad1fc2ae4 Reviewed-on: https://gerrit.libreoffice.org/79543 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-24loplugin:returnconstval in sal..scNoel Grandin
Change-Id: I300d14d580d450ec338129918955651b9d40d5d2 Reviewed-on: https://gerrit.libreoffice.org/78059 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-12Fix typosAndrea Gelmini
Change-Id: I94d0e85c731801b8b0ec844ae2a8f268b2f1022e Reviewed-on: https://gerrit.libreoffice.org/77256 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-07tdf#126673 Auto-fit column and auto-fit row don't work with line breakNoel Grandin
Revert "tdf#94677 Calc is slow opening large CSV, avoid reset SetUpdateMode" This reverts commit c47d0174f2c6c3ebcb3b33276d0277e7aceac330. Change-Id: I38e065d44dfb9d08498176b8231aff14ff51d91c Reviewed-on: https://gerrit.libreoffice.org/77109 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-25tdf#94677 Calc is slow opening large CSV, avoid reset SetUpdateModeNoel Grandin
Avoid resetting SetUpdateMode in CreateFieldEditEngine while calculating row height. This takes the time from 1m25 to 49s for me. Change-Id: If406eac1a8b031f1734d9c2376c413dfa22d89f8 Reviewed-on: https://gerrit.libreoffice.org/74630 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-21reference childwins are all weldedCaolán McNamara
Change-Id: I050b4bdff4eaa645316538725c69e83bee4a90c5 Reviewed-on: https://gerrit.libreoffice.org/74526 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-05-16optimize ScHTMLExport::WriteTables() with large columnsLuboš Luňák
Again, unless given a hint, mdds always starts a search from the beginning of the container, so iterating over a column becomes quadratic. Shows when selecting (the title of) a large column with different value types, e.g. in tdf#120558, which triggers setting the selection from VclQt5Clipboard::setContents(), which calls this. Change-Id: Ida009c5ddf18ccdc8dff88c15530cc7e33ce80e7 Reviewed-on: https://gerrit.libreoffice.org/72366 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-05-15tdf#123762 Cell anchored object is deleted if cell is deletedIlhan Yesil
If an object is anchored to a cell, then it is expected that this object belongs to this cell and it's survive after a deletion of the cell makes no sense. So the anchored object will be deleted together with the cell. Objects anchored to the page are not affected. Change-Id: I91f24bf92ab5329aba1d053b3cf5fba77bf16e4f Reviewed-on: https://gerrit.libreoffice.org/69390 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2019-05-09loplugin:unusedmethodsNoel Grandin
Change-Id: I7b4d2e5e611935284e2902b0089950768dfb7717 Reviewed-on: https://gerrit.libreoffice.org/72036 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-26ScPatternAttr needs to be a complete type here (Windows --disable-pch)Stephan Bergmann
Change-Id: Iafbdd3b7e872cd15718879e5c7f1256069156d5f Reviewed-on: https://gerrit.libreoffice.org/71343 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-04-21tdf#81765 slow loading of .ods with >1000 of conditional formats, part 3Noel Grandin
This takes the loading time from 14s to 13s Use a o3tl::sorted_vector to reduce searching time Change-Id: I947a3e5001fe1058cf9bffc9509d026af4122ef4 Reviewed-on: https://gerrit.libreoffice.org/71035 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-21tdf#81765 slow loading of .ods with >1000 of conditional formats, part 2Noel Grandin
This takes the loading time from 15s to 14s. Reduce unnecessary allocation/copying by passing down ownership of the newly created ScPatternAttr to the item pool Change-Id: Iec38bbff572d10ff8d86f5e65fbe9a96b6a5a706 Reviewed-on: https://gerrit.libreoffice.org/71010 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-18crashtesting: failure on import of ooo6593-5.stcNoel Grandin
since commit 7282014e362a1529a36c88eb308df8ed359c2cfa Date: Fri Feb 1 15:15:16 2019 +0100 tdf#50916 Makes numbers of columns dynamic Change-Id: I858e61b3a1158bf47b5855e56d63c77cc87aa09b Reviewed-on: https://gerrit.libreoffice.org/70902 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-18crashtesting: failure on export of ooo118068-1.ods to odsNoel Grandin
since commit 7282014e362a1529a36c88eb308df8ed359c2cfa Date: Fri Feb 1 15:15:16 2019 +0100 tdf#50916 Makes numbers of columns dynamic Change-Id: Ib8dc06b80beed81a2543f343483599c425e87369 Reviewed-on: https://gerrit.libreoffice.org/70901 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-12loplugin:unusedmethodsNoel Grandin
Change-Id: Ie90e53583484ee4f378ec92634adf3be7cd9ecbb Reviewed-on: https://gerrit.libreoffice.org/70650 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-05tdf#50916 Makes numbers of columns dynamic.Noel Grandin
With this commit we are making numbers of columns dynamic, but the number of maximum supported columns will be the same (1024). Such approach will allow us to check issues (eg. performance, LO format etc.), and improve it. Increasing number of maximum columns, will be done in separate commit. Change-Id: Ibac4101e9ffc05e3548eca1c198f6319ac7ff9aa Reviewed-on: https://gerrit.libreoffice.org/44802 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2019-03-01do not call GetFormatTable() from GetNonThreadedContext() (tdf#121949)Luboš Luňák
ScDocument dtor calls ClearLookupCaches(), which calls GetNonThreadedContext(). But ScDocument instances used for copy&paste GetFormatTable() fails on null mxPoolHelper, because ScDocument ctor doesn't set it in such a case. So set up the pointer in ScInterpreterContext on demand only if actually needed. Change-Id: If3811da5bb00a2d7d404c089ee1bf46037a2cddb Reviewed-on: https://gerrit.libreoffice.org/68350 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2019-02-18tdf#122624 XLSX OLE in DOCX: import view positionsLászló Németh
of the visible sheet of an embedded spreadsheet, instead of showing always the first column and row. Change-Id: I7b712d97f152da3cecf8371e21cf0a82ef21f199 Reviewed-on: https://gerrit.libreoffice.org/67867 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-02-11tdf#121388 : Disable threading and dep evaluation for IF...Dennis Francis
IFS/SWITCH if the call did not originate from ScDocShell::DoRecalc()/ScDocShell::DoHardRecalc() Change-Id: Ifdb3a496276dc841fc42a1bad1876cfb1057baf6 Reviewed-on: https://gerrit.libreoffice.org/67414 Tested-by: Jenkins Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
2019-02-05Allow computing spans of formula-groupsDennis Francis
Includes unit tests for correctness of the new functionality. Change-Id: I35f7449006d973de006a756664ae468b9a0dcb31 Reviewed-on: https://gerrit.libreoffice.org/66841 Tested-by: Jenkins Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
2019-01-29pass ScConditionalFormat around by unique_ptrNoel Grandin
Change-Id: If15ac08d8334a386312870d3ebebb385cf55e5f6 Reviewed-on: https://gerrit.libreoffice.org/67050 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-24loplugin:constparams in scNoel Grandin
Change-Id: Ie211eea01eaceb718f701d3fdbb6253700d14e5e Reviewed-on: https://gerrit.libreoffice.org/66831 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-16pass ScPostIt around by unique_ptrNoel Grandin
Change-Id: I99c1f0a5d5c760663f5150b477a936d2f45b874c Reviewed-on: https://gerrit.libreoffice.org/66322 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-14avoid possible expensive repetitive formula group changes (tdf#102364)Luboš Luňák
The testcase from tdf#102364 is actually a rather pathological case, the document having a full 1M cells column with the same formula, and doing undo in this case essentially pastes the column over itself (I think a column is first deleted, which moves this column, and then ScUndoInsertCells will trigger ScMoveUndo::UndoRef(), which will paste the column in that place again. And since this is done cell by cell, removing old cell first splits the large formula group and then adding a new cell with the same formula rejoins the formula group, and setting these formula group changes for all the cells over and over actually takes a long time. Avoid that by delaying the formula grouping operation and do it just once at the end. I'm not sure if this is that good way of handling this, given the testcase is very specific, but I can imagine something similar happening in other possible cases (manual copy&paste of a large column over itself or moving it slightly up or down). Change-Id: Ie4241197103a039c232150333250f78175b1c2c7 Reviewed-on: https://gerrit.libreoffice.org/64782 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <libreoffice@kohei.us> Reviewed-by: Eike Rathke <erack@redhat.com>
2018-12-08Clean up LIBO_INTERNAL_ONLY uses of SAL_WARN_UNUSED_RESULTStephan Bergmann
Change-Id: I98b2d90c8345f07010f6defd82557188d5cd35c7 Reviewed-on: https://gerrit.libreoffice.org/64808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07Find actual data area inside the main-range...Dennis Francis
and trim all ranges to match this actual data area. Don't do this optimization for COUNTIFS where there is no main-range. This optimization is also turned off if any of the parameter ranges are not double-refs. Benefits in cases like - =SUMIFS(A:A, B:B, ">=20", C:C, "<=10") and the is data only in say A1:A10000 and rest are empty. Range trimming in this case saves lot of execution time and memory (for vConditions and vRefArrayConditions). Change-Id: I6b4ad91e23f89dc48603b98000bcef4dbdb03112 Reviewed-on: https://gerrit.libreoffice.org/64657 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2018-12-03make sure FetchVectorRefArray() never triggers Interpret()Luboš Luňák
Test::testFormulaRefUpdateRange could trigger this, leading to recursion that wasn't handled properly by the code, since it wasn't expected to happen at late time (ScDependantsCalculator should have already caught it). This is all caused by the fact that FetchVectorRefArray() fetches also all rows before the given rows (to make the caching simpler I suppose). But that fetching could lead to Interpret() calls. Therefore, make ScDependantsCalculator in OpenCL mode check also all rows above. Change-Id: Iaecc105663df21b01443759287cec605470d34a5 Reviewed-on: https://gerrit.libreoffice.org/64236 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2018-11-21tdf#42949 Fix IWYU warnings in include/vcl/[B-E]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Iabe571aa8f00492902c499094bea8365a3e17fca Reviewed-on: https://gerrit.libreoffice.org/63623 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-11-15loplugin:staticmethods in scNoel Grandin
Change-Id: I3cdce43e0ba9b17f9bf993ebcad5f64f0834ceaf Reviewed-on: https://gerrit.libreoffice.org/63421 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-15Cache the vConditions array...Dennis Francis
used in ScInterpreter::IterateParameterIfs(). Store this cache as a member of ScInterpreterContext (maConditions). Create a static pool of ScInterpreterContext's so that the embedded maConditions is reused everytime a formula-group/ formula-cell is calculated. There needs to be two separate static pools - one for threading, one for non-threaded computation of formula-cells. With this, we can have better performance of the cached maConditions as well as mScLookupCache. In threaded case there is no recursive computation of cells as dependencies are all pre-computed. The thread-indexed lookup cache array in ScDocument is removed as now the lookup caches on context lives as long in the static context pools. This cached vConditions array can take advantage when there are lots of SUMIFS/COUNTIFS with arguments of similar dimensions in the document. Otherwise it will be allocated from scratch for every COUNTIFS/SUMIFS formula-cell. Change-Id: I654b05e55035ce6efcf07d32d36623c9d76b0ff6 Reviewed-on: https://gerrit.libreoffice.org/63066 Tested-by: Jenkins Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
2018-11-14make ScInterpreterContext also accessible without passing it aroundLuboš Luňák
E.g. ScModelObj::GetFormatter() can be rather deep in the call chain and it just doesn't make sense to pass ScInterpreterContext* to all the relevant places (and it's a question if it makes sense to pass it around at all, googling shows that thread_local is not really _that_ slow). Change-Id: I9114ef8a10d82a10968391718099edccde7a2663 Reviewed-on: https://gerrit.libreoffice.org/63184 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2018-10-22Remove ScLookupCache from ScLookupCacheMap it had been added toStephan Bergmann
...instead of removing an arbitrary ScLookupCache with a matching ScRange from the first ScLookupCacheMap that happens to contain one. 79449d73900d7a9bf061244d76f5f8eecc441198 "make VLOOKUP in Calc thread-safe" introduced per-thread ScLookupCacheMaps, so that multiple ScLookupCacheMaps can contain ScLookupCaches with identical ScRanges. For example, UITest_calc_tests6 adds ScLookupCaches for ScRange 1!R2C18:R97C18 to different threads' ScLookupCacheMaps. That causes confusion so that calling ScDocument::RemoveLookupCacheHelper to remove an ScLookupCache from a mismatching ScLookupCacheMap accesses a different ScLookupCache* pCache = (*it).second.release(); that may already have been destroyed; see failing ASan/UBSan builds like <https://ci.libreoffice.org//job/lo_ubsan/1067/>. Change-Id: I70c33b236dc502b8a98e0e313d422424eec5dbca Reviewed-on: https://gerrit.libreoffice.org/62194 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-10-15loplugin:constfields in scNoel Grandin
Change-Id: If326175d571d15752efd1b63df45b2bc785f7541 Reviewed-on: https://gerrit.libreoffice.org/61653 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-10make VLOOKUP in Calc thread-safeLuboš Luňák
There is mutex protection needed for accessing the same SvtBroadcaster when calling StartListeningArea(). Also some of the memory management and caching needed fixing. Change-Id: Ia57ed85286cf195521719cfd3b320f73a6342bb1 Reviewed-on: https://gerrit.libreoffice.org/61187 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2018-10-10ColumnSpanSet variant optimized for just one ScRangeLuboš Luňák
Since ScInterpreter::IterateParameters() iterates over just one range, there's no point to to set flags for that range and then generically walk over that range, just directly use the range. Change-Id: I13003eb09bd98f145e9ead5e485596168d9399cb Reviewed-on: https://gerrit.libreoffice.org/60866 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2018-09-12loplugin:useuniqueptr in ScInterpreterNoel Grandin
the ScInterpreterTableOpParams are allocated and deleted in the same method, so the vector in ScDocument doesn't actually need to own them Change-Id: Icd5a33c891e608abc0843c144d7a53f44c3ac02f Reviewed-on: https://gerrit.libreoffice.org/60354 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-22loplugin:useuniqueptr in ScLookupCacheMapImplNoel Grandin
and simplify Change-Id: Ic5ec97680349a1ea837891b2300dff05cd00026f Reviewed-on: https://gerrit.libreoffice.org/59431 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-15pass ScPrintRangeSaver around by std::unique_ptrNoel Grandin
Change-Id: I5b5ffe9f421b63951b05d9d6f58af346b8fdf0d1 Reviewed-on: https://gerrit.libreoffice.org/59029 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-02-06 12:53:12 +0000