summaryrefslogtreecommitdiff
path: root/sc/source/core/data/table3.cxx
AgeCommit message (Collapse)AuthorFilesLines
2024-04-02tdf#146619 Remove unused #includes from C/C++ filesRafał Dobrakowski1-1/+1
'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-175/+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-01-13cid#1546354 COPY_INSTEAD_OF_MOVECaolán McNamara1-4/+8
and cid#1546319 COPY_INSTEAD_OF_MOVE cid#1546286 COPY_INSTEAD_OF_MOVE cid#1546283 COPY_INSTEAD_OF_MOVE cid#1546191 COPY_INSTEAD_OF_MOVE cid#1545953 COPY_INSTEAD_OF_MOVE cid#1545874 COPY_INSTEAD_OF_MOVE cid#1545857 COPY_INSTEAD_OF_MOVE cid#1545781 COPY_INSTEAD_OF_MOVE cid#1545765 COPY_INSTEAD_OF_MOVE cid#1545546 COPY_INSTEAD_OF_MOVE cid#1545338 COPY_INSTEAD_OF_MOVE cid#1545190 COPY_INSTEAD_OF_MOVE cid#1545272 COPY_INSTEAD_OF_MOVE cid#1545242 COPY_INSTEAD_OF_MOVE cid#1545229 COPY_INSTEAD_OF_MOVE Change-Id: I88813d9dbd87ce10375db8198028f8b70e23f0fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162027 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-03tdf#114441 Convert use of sal_uLong to better integer typesgilssonn1-1/+1
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)1-31/+17
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-29sc: fix back color filter entriesHenry Castro1-0/+6
The function "GetFilterEntries" iterates only that contains cell data value entries, the background color filter feature requires to iterate background color attribute which is not stored in multi type vector cells. Signed-off-by: Henry Castro <hcastro@collabora.com> Change-Id: I372db48d2399f62712f642eefdbfea8885b09f58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159864 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 826eae46095b2184554565bab1792e96964a720f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159905 Tested-by: Jenkins
2023-11-07ITEM: Get away from classic 'poolable' Item flagArmin Le Grand (allotropia)1-4/+4
To understand this, some look back in history will be needed to see why it is as it is today. In some (reworked) comments 'poolable' is described as flag to hold Items in the ItemPool, also always having only one incarnation of each possible Item. This is not the original intention, but a side-effect. The reason is what the binary format in the office did: To save a document, the Objects & the Pool were saved, *not* individual Items *together* with the objects. The Pool was completely (binary) saved (and loaded) in one run. Temporary IDs were used to represent at the objects in file which Items were referenced. This *required* to have only one incarnation per item to have a minimal binary file size, thus this high effort was put into this. At doc load, the pool was loaded, all Items were set to RefCount 5000, the references from the objects were restored and then for each Item the RefCount was lowered by 5000 again and - if being zero - deleted. Items for UI were marked 'non-poolable' to *not* safe them with the document, so poolable was a flag to decide if that Info/Item was to be saved with the document - or more direct: if it is Model Data. Items are small, so if we prefer runtime it is okay to no longer being strict with this, anyways does not happen often and has only marginal memory effects - compared to runtime effects/savings. Other problems which this caused: One example is that objects in the UNDO stack were still in the pool, so e.g. deleted pictures were saved with the document despite no longer being used (!). That is the reason we have an UndoItemPool and a method MigrateItemPool to move stuff to that Pool when objects go to the UNDO stack - all of this is also no longer needed. Cleaning this up means to ideally have all items in the SfxItemSet, no longer at the Pool. The Pool should be reduced to a 'Default-Item- Holder' and a 'Slot-to-whichId-mapper'. This needs thorough cleanups/removals, but will be worth it because that massive simplification(s) will increase safety an runtime and make migrating to the goal of completely type-based ItemSet stuff easier for the future. Hopefully only view code in the office working with items will have to be changed for this. In this 1st step I already found that some 'compromizes' will be needed: - There are still Items that have to be at the pool to make the Surrogate-stuff working. This gives back all Items in a Pool of a type and is used in ca. 80 cases. Each one looks at these Items *without* context (e.g. a SfxItemSet at an Object would be a context), so if e.g. a dialog is open that temporarily uses Items of that type you would also get these - without knowing about it... To make that work there is still a mechanism to have Items at the Pool, but now just *registering* (and un-reg) them without any sort/search/ remove needs. Also only for Items that need that, so I evaluated the GetItemSurrogates calls and added some asserts when GetItemSurrogates tries to access an unregistered item type which needs to be added. - Another caveat is that there are about 250 places that directly put Items to the Pool (not all remove these, that is done at pool deletion, so some kind of silent 'garbage-collection' is in place). To have an overview I renamed the accessing methods to separate them from the same functionality at the SfxItemSet, which had the same names. An implementation does still add these directly to the pool, there is no way to cleanup those usages for now. In principle all these should be changed to hold the data at an SfxItemSet. I am still hunting problems. But you can build the office, all apps work (including chart) and you can do speed comparisons already. There are test throwing errors, so I hunt these now. It is hard to give an estimation about how much more changes/corrections will be needed. Completed adaptions to new registered Items at Pool, that reduces the failing tests. Still many that I need to hunt. Added stuff to work around that 'compromize' in ScDocumentPool: It overloads ::PutImpl of the pool to implement special handling for a single Item in SC, the ScPatternAttr. In former code that method was used from SfxItemSet and ::PutImpl at the pool directly, so it was only used in one place. I am not sure if it was used from the SfxItemSet functionality, but better offer it for now. To not waste too much runtime the callbacks depend on the boolean 'NewItemCallback' at the SfxPoolItem, it gets set for that single Item in SC and only then the callbacks trigger. I hope to get rid of those again, e.g. newItem_UseDirect is only needed since we have no 'real' StaticPoolDefaults currently - another thing that needs to be cleaned up in a next step. Since usages of impl(Create|Cleanup)ItemEntry and Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it globally available in svl and use it also directly for Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that fallback (e.g. tryToGetEqualItem) was used before, thus this is the same class of errors (SfxPoolItem ptr-compare) as the others which I will need to find anyways. Also fixed some missing stuff. Have now idenified and redirected all SfxPoolItem ptr-compares to be able to debug these - one cause for the remaining errors is probably that before with bPoolable those often were sufficient, but are no longer. Used the [loplugin:itemcompare] and a local clang build to do so, see https://gerrit.libreoffice.org/c/core/+/157172 Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter to implCreateItemEntry to signal that it gets called from DirectPool stuff - currently needed. Hopefully when getting rid of that DirectPool stuff we can remove that again Added two more debug functionalities: - Added a SerialNumber to allow targeted debugging for deterministic cases - Added registering & listing of still-allocated SfxPoolItems at office shutdown Found PtrComp error in thints.cxx - POC, thanks to areSfxPoolItemPtrsEqual. Will hopefully help more with other tests Found some wrong asserts/warnings where I was too careful and not finding something/succeeding is OK, fixes some UnitTests for SC For SC I now just tried to replace all areSfxPoolItemPtrsEqual with the full-ptr-content compare SfxPoolItem::areSame. I also needed to experiment/adapt the newItem_Callback solution but got it working. Did that replacement now for SW too, found some places where the direct ptr compare is OK. Continued for the rest of occurrences, now all 160 places evaluated. Also done some cleanups. Massive cleanups of stuff no longer needed with this paradigm change. Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now. It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that already needs many exceptions. Also useful for testing if errors come up on this change to test if it is related to this. Added forwarding of target Pool for ::Clone in SvxSetItem and SvxSetItem, simplified SfxStateCache::SetState_Impl and returned to simple ptr compares in SfxPoolItem::areSame to not do the test in areSfxPoolItemPtrsEqual. Debugged through UITest_calc_tests9 and found that in tdf133629 where BoxStyle is applied to fully selected empty calc the Item- reuse fallback has to be used not only for ATTR_PATTERN, see comment @implCreateItemEntry. Maybe more... Problem with test_tdf156611_insert_hyperlink_like_excel. Found that in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField is found and returned as ptr, but it's usage crashes. That is due to the SfxItemSet aEditSet used there gets destroyed at function return what again deletes the SvxFieldItem that is holding the SvxURLField that gets returned. This shows a more general problem: There is no 'SfxPoolItemHolder' that safely holds a single SfxPoolItem - like a SfxItemSet for a single Item (if Items would be shared_ptrs, that would be a safe return value). That will be needed in the future, but for now use another solution: Since I see no reason why EE_FEATURE_FIELD should not be shareable I wil change this for ow in the SfxItemInfo for EditCharAttribField. That way the Item returned will be shared (RefCnt > 1) and thus not be deleted. I changed the return value for GetURLField() and GetFirstURLFieldFromCell() in ScEditShell: At least for GetFirstURLFieldFromCell the return type/value was not safe: The SvxFieldItem accessed there and held in the local temporary SfxItemSet may be deleted with it, so return value can be corrupted/deleted. To avoid that, return a Clone of SvxFieldData as a unique_ptr. With all that UnitTest debugging and hunting and to get the paradigm change working to no longer rely on shared/pooled items I lost a little bit focus on speed, so I made an optimization round for the two central methods implCreateItemEntry/implCleanupItemEntry to get back to the speed improvements that I detected when starting this change. It was mainly lost due to that 'strange' chained pool stuff we have, so I added to detect the target pool (the one at which the WhichID is registered) directly and only once. Next thing to cleanup will/should be the pool and it's concept, all this is not needed and really costs runtime. Since implCreateItemEntry/implCleanupItemEntry are executed millions of times, each cycle counts here. Had an error in the last changes: pool::*_Impl methods use index instead of WhichID - most of them. Another bad trap, I really need to cleanup pool stuff next. Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-08tdf#95520 Autofilter: Sort by colorSamuel Mehrbrodt1-0/+31
Change-Id: I2c1455cc2c741d16f09eccee0bf489f8990684f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151064 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2022-12-22tdf#152535 Provide better localization for "Grand" subtotal stringsRafael Lima1-1/+25
As discussed in the bug report, having the word "Grand" hardcoded first in subtotals is not great for translation, since for some languages the translation of "grand" would come second. This patch creates separate strings for each case of Grand, f.i. "Grand Count", "Grand Sum" and so on. Now each of them will have their own translation. Change-Id: Ib875bc1a7b2fcc8934ad85bfe09374f8d9d9a179 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144666 Tested-by: Jenkins Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
2022-10-11tdf#91305 related: Drop redundant only-one-column/row checkMike Kaganski1-16/+0
This check was introduced in commit 4cd9e45a439b654c8e1ff7983fe7e4bd073b9c92 Author Yan Pashkovsky <yanp.bugz@gmail.com> Date Fri Aug 12 23:39:30 2016 +0300 tdf#91305 fix sort calc Then commit 63592999a067d76c896ed79204330e1a4b934c80 Author Eike Rathke <erack@redhat.com> Date Thu Aug 18 17:16:50 2016 +0200 refine HasColHeader()/HasRowHeader() conditions, tdf#91305 related made the "not only one column/row" case check the same. Change-Id: I25ce867e1c64d7b89a617021de9a5e4f1c89d2a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141219 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-07-27Name FilteredRow what it is, not hidden; tdf#117276 follow-upEike Rathke1-3/+3
Also avoid defaulted parameter, it's only one more place to change. Change-Id: I64468fcd7085eff7a49bd0c359fdf14a31058af6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137511 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-07-22tdf#117276 sc: Show hidden filter elements as inactive elementsBalazs Varga1-1/+5
Showing hidden values in the autofilter dropdown (as inactive when it was hidden by another row) - without changing the behaviour of autofilter. First those which belongs to non-hidden rows, then those which belongs to hidden rows. TODO: maybe we can add a global option where the user can switch on/off this feature. Change-Id: Iafeb43176efe7ab422b22697d399c68c95d0319d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136595 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2022-06-18create getter for ScCellValue::mpFormulaNoel Grandin1-10/+10
so we can assert that it has the correct tag type Change-Id: Iab13a6d6ea1783c69395f06f28732769e5fe8b18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136059 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-17create getter for ScCellValue::mpEditTextNoel Grandin1-1/+1
so we can assert that it has the correct tag type Change-Id: I984c22ae2527d652f2d4194227dc1173793300c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136054 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-17create getter for ScCellValue::mpStringNoel Grandin1-3/+3
so we can assert that it has the correct tag type Change-Id: I8933919aefc2bb22694a283b54dc3de11d16e5a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136002 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-16create getter for ScCellValue::mfValueNoel Grandin1-1/+1
so we can assert that has the correct tag type Change-Id: I0d626130cb014e19239e88a6988018c83d061f68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136001 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-16make meType in ScCellValue privateNoel Grandin1-3/+3
as a first step to wrapping up the internals of this class and adding some asserts Change-Id: Ic13ddd917948dbf3fd6d73f44b8efcc727726baf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135994 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-18make CreateColumnIfNotExists() non-constLuboš Luňák1-7/+13
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-04-21rework GetColumnsRange() and ScColumnsRangeLuboš Luňák1-2/+2
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-03-30allocate columns for initDataRows()Luboš Luňák1-0/+4
Triggered by TestSort::testSortImages() with INITIALCOLCOUNT set to 1. Change-Id: Ifd3e63de6411e0a4d8776ed6cc8a7b6c7c64eec6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132283 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-29allocate columns in ScTable::Compare()Luboš Luňák1-0/+2
This gets triggered by ScCellRangeObj::testSortOOB() if INITIALCOLCOUNT is set to 1. Change-Id: I4d9715e89403072b312c0002a43c67ac59960d1a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132281 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-08proper columns range check (tdf#147830)Luboš Luňák1-1/+1
Change-Id: Ib23bc3f194fa418035e7c70a4f3e1b682f9c46b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131181 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-06do not destroy broadcasters and then recreate again (tdf#134268)Luboš Luňák1-0/+2
Sorting ends tells all listeners on all the sorted cells to end listening to stop updates, then sorts the cells and starts listening again. This will cause all broadcasters for the sorted cells to temporarily stop having any listeners, so they'll be deleted and removed from the mdds vector (which may additionally cause moving large parts of the mdds vector repeatedly). And since all listeners will want to listen again after the sort, this will all need to be reconstructed. To avoid this, temporarily block this removal and then later just checks and remove any possibly left-over broadcasters that ended up with no listeners. Change-Id: Ie2d41d9acd7b657cf31a445870ce7f18d28d5ebb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131069 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-03improve ScMark* classes a bitLuboš Luňák1-2/+2
Bin pointless empty destructors, make trivial functions inline, return value by simply returning it. Change-Id: Ia71e73262802bbe6b022ca4bafb2b958ffdf39f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130915 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-02-23check valid col in ScTable::GetDataEntries()Luboš Luňák1-0/+2
Presumably uncovered by 823eb92025853d120c17790d1c8efde59f033c69 no longer allocating a column on GetPattern(). Change-Id: I2f23414a912ec1a0f22b4b88ea367423fb6fb7e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130388 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-02-14Recheck modules s[a-c]* with IWYUGabor Kelemen1-3/+0
See tdf#42949 for motivation Change-Id: I867e1f7a2c44210de3281b36e22708a5d32ddb7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129476 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-02-10replace various sal_uLong that might overflow with huge sheetsLuboš Luňák1-8/+8
16Mx16k cells is more than 32bit, so things like cell counts or progress -> sal_uInt64. Height/widths of complete rows/columns -> tools::Long. Change-Id: I8077ec0c97782310db024c20c335cfcbc3833227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129634 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-12-05move entire ScTable::ValidQuery() into (Sc)QueryEvaluatorLuboš Luňák1-950/+5
This reduces the number of arguments passed around, removed the need for ValidQueryCache (as the data can be now cached in the class itself), it'll allow even more optimizations, and it also makes the by now rather large (almost 1000 lines) helper class a proper class instead of tons of inline code. Change-Id: I585cf580b3e7b2d4512aa535176e97c0abfd547a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126367 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-29store ScQueryEntry simply by valueLuboš Luňák1-2/+2
There's not much point in complicating this by allocating them dynamically if they're always treated by value anyway. Change-Id: I8325829201c0ad6c95858916a94c5b4d1d208b1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126024 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-26cid#1494444 silence Dereference null return valueCaolán McNamara1-0/+1
Change-Id: I7c6c60489a58378238ff63ff9c6b45f3a7aa4bf7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125866 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-11-25sort, cache and binary search query items if they're many (tdf#136838)Luboš Luňák1-14/+54
This makes autofilter even with tdf#136838 almost instanteous. Change-Id: I94b4b6d6ab6f8e73312d88c8b88c0f393707f117 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125795 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-25fast query item searching also for ByValue with stringLuboš Luňák1-3/+14
The tdf#136838 comment #2 document has MaterialNumber column that is actually strings (even though they look like numbers), but autofilter creates ByValue query items (for whatever reason). So extend the conditions for fast searching to include this case, otherwise it'd be handled by the generic slower code. Change-Id: I0fe192b99cd2999282db53ba98587b712c42c762 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125794 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-25avoid repeated checks with same result on fast lookup pathLuboš Luňák1-45/+74
Change the compareByString() function to a template with a bool parameter that will disable all the checks, allowing the compiler to effectively generate just a small inline function. And then compute the bool value once and call the fast version if true. With comment #2 in tdf#136838 this actually saves 40% of time. Change-Id: I5a5190f19a1df163b28e527090ec880e6de5bbda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125768 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-25try to search efficiently with a query with many items (tdf#133867)Luboš Luňák1-22/+99
Autofilter with large documents can create queries that have thousands of items. Searching all of those for every cell using the generic algorithm can be quite slow. First try an optimized search for this case that skips most of the complications and just tries to find in the query items an exact match for the cell. This significantly speeds up tdf#133867 or attachment from comment #2 in tdf#136838. Change-Id: I2bba18da6a101c76398d8c42c4306c53682899c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125746 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-25don't fetch cell string content for each query item (tdf#133804)Luboš Luňák1-18/+20
When using autofilter, the query entry can have thousands of items, and fetching of the cell string value is not trivial in some cases. I'm not doing this for numeric values, as those depend on query items and also seem fairly fast. Change-Id: I01fa2e0cbce8f770d1ed079c0dba74830402a895 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125735 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-24Fix typosAndrea Gelmini1-1/+1
Change-Id: Ibc2eb80d7cc0cfc22c7fea0dc7ebe495ae0927c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125765 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-11-24remove superfluous code that has a TODO note about itLuboš Luňák1-14/+0
The commits introducing this part of code have tests attached, so it's fairly easy to check that this part of code is in fact not necessary, but if in doubt there's the option of simply asking the author of the code. Change-Id: I3b754090ac462d3ae8e4676fc1643570ec53aac1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125695 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-23short-circut SC_AND lookup if left side is known to be falseLuboš Luňák1-0/+12
Change-Id: Ia1badb975f4effca668a5c2a41cfef3beccf8e2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125739 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-23do not wait for condition that's not neededLuboš Luňák1-4/+4
When not querying for the test equal condition, it's pointless to keep searching for it to become true only to throw it away. Change-Id: Ie861bac141f80025e95753fb8b1202498df17383 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125733 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-23move code to a separate functionLuboš Luňák1-57/+64
To be extended in following commits. Change-Id: I09eaf0f5cfdbbe0aff254231dbb983fd7f72cc5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125732 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-23do not fetch cell data if ScRefValueCell can tell thatLuboš Luňák1-10/+2
Change-Id: I2910231c9cf205ce697616e660e49056c221e89d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125731 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-23do not try to read table cell again on ScRefCellValue::isEmpty()Luboš Luňák1-96/+64
The ScRefCellValue is always initialized to point to the relevant cell. Originally there used to be a cell pointer that could be null, but since 43e50ec759200fe166dba59d3ff76af2a2e148c8 it's been always set and so checking again is pointless. Change-Id: Ib661ec5de73891ed3a5cd0346287324183721806 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125687 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-22cache error strings for ScTable::validQuery() (tdf#133835)Luboš Luňák1-5/+23
Avoid calling SharedStringPool::intern() on values that are repeatedly the same. Change-Id: I094f2e777a4ca24536e0c25e6a1c6358ccf49f61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125660 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-17revert "vlookup - optimize SC_EQUAL and NOT_EQUAL." (tdf#139612)Luboš Luňák1-9/+0
That commit breaks lookup when the "Search criteria = and <> must apply to whole cells" option is disabled, as it enforces whole cell checking regardless of the option. Given that the option is enabled by default in LO ('SearchCriteria' in Calc.xcs) and it's what MSOffice does as well, and this default gives good performance regardless of the option, I don't understand the purpose of the commit. Possibly it was based on a document where somebody disabled the option and then indeed got worse performance. Solution: Don't do that :). This reverts the code parts of a953fa1c0f6a40a08859570516c511f3a841 . The test I've kept but switched to ensure that partial matching does work if the option to match whole cells is disabled. I've also changed the tooltip for the option to mention performance and not suggest that off is the default. Change-Id: I56d7b6e7b8e9f0622f7ad6d447daf56c3b705a7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125267 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-15Revert "improve performance of cell equality comparisons)" (tdf#139612)Luboš Luňák1-8/+2
This reverts commit 5e9c2677e8fcd19b289d947b94ceba52b138728b. Reason for revert: I based this on code that tdf#139612 talks about, and which is possibly incorrect. Change-Id: Ie9e46a19ac8fe10bbf6cf6f429741200684d5bfd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125138 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-08improve performance of cell equality comparisons (tdf#139444)Luboš Luňák1-2/+8
When comparing cell and a string for (in)equality, that means comparing the whole cell, even when not explicitly asked for. Whole cell comparison is simpler and faster. Change-Id: Ic7a79b20f710f2a5d84f62c714d67c088a22d449 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124881 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-08optimize VLOOKUP by returning SharedString if possible (tdf#139444)Luboš Luňák1-2/+9
Profiling shows that the slowness mostly comes from converting the cell's SharedString to OUString and then the comparison converts it back. To improve performance, return the SharedString if possible and ignore the OUString. Change-Id: Idb190bd0354cea3185e5ff9ebaf92cab63f23f70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124880 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-08make a number of Calc functions return value by actually returning itLuboš Luňák1-23/+18
All these returned their value using a reference argument, for apprently no good reason. Change-Id: I6a33417e7df2aac67427c16e5003dfaaa1a814d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124872 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-16Simplify vector initialization in scJulien Nabet1-8/+10
Change-Id: If5b7632cfbc81f89d68ce8fbce1fac265e8354fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123692 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-11loplugin:moveparam in scNoel Grandin1-3/+3
Change-Id: I4b9d45a6b0231841a5fe00d0193a8530b9e05559 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123389 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-25 11:21:23 +0000