summaryrefslogtreecommitdiff
path: root/sc/source/ui/unoobj/cellsuno.cxx
AgeCommit message (Collapse)AuthorFilesLines
12 daystdf#167178: make sure to synchronize the tab in AdjustUpdatedRangesMike Kaganski1-9/+30
The change could adjust the tab in the aRanges; but aRange still has the original tab number. It needs to be updated. Regression after commit a0403b6eb25a99f6225e0f77f4b14d78f4045c9e (tdf#47479: Do not modify range of sheet / column / row in notifications, 2025-05-02). Change-Id: I248f5575ffc7fe388a65cb8bc0007ec72d9f2129 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186906 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2025-05-26ScPrintFunc, ScPrintFuncCache: pass ScDocShell by refXisco Fauli1-4/+4
Change-Id: If71f61c9b5e75e4035c6066fe07aeb747a3d08bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185811 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2025-05-23ScSimpleUndo: pass ScDocShell by refXisco Fauli1-6/+6
Change-Id: If3d1b364836922c210ffbbf8046ea98d912892b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185712 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2025-05-23tdf#166684 strip out some unnecessary UNO work (2)Noel Grandin1-2/+20
to make this easier to optimise, strip out some unnecessary UNO stuff between the import filter and the underlying spreadsheet model Change-Id: I0c1e12c09842390c90a7e804dffa5fdd034f60b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185648 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2025-05-23tdf#166684 strip out some unnecessary UNO workNoel Grandin1-0/+58
to make this easier to optimise, strip out some unnecessary UNO stuff between the import filter and the underlying spreadsheet model Change-Id: I5d0ea6ffc487f089c87f17fd2eb18a30198dbacc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185647 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2025-05-16ScEditUtil::GetString: pass ScDocument by refXisco Fauli1-1/+1
allowing to drop ScGlobal::GetStaticFieldEditEngine(); It was added in commit 1ecdc7aaf661e97a33cf521f553481d79cd26de2 Author: Eike Rathke <erack@redhat.com> Date: Thu Jul 25 15:33:49 2013 +0200 resolved fdo#67249 use ScFieldEditEngine to resolve field content Also adapt the testRichTextContentODS unittest Change-Id: I06eb1b2b4fcc35867531c645098d854dd9907bc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185406 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2025-05-16ScConditionalFormat: pass ScDocument by refXisco Fauli1-7/+7
and in other related places Change-Id: Ic4fd970c0f91f246893013f0751376043dd809f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185361 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2025-05-02tdf#47479: Do not modify range of sheet / column / row in notificationsMike Kaganski1-12/+36
Change-Id: I2c5afa5397e3a98806908a2f73f8d654e83fb890 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184889 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2025-04-06tdf#151876 shave some time off chart load (3)Noel Grandin1-3/+1
reduce the number of times we acquire/release the solarmutex in the hottest part of the load. Change-Id: I840e4b1bdb489319c6b03d9bfa69e761eb448831 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183756 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2025-04-06tdf#151876 shave some time off chart loadNoel Grandin1-0/+40
reduce the number of temporary UNO objects we create Change-Id: Ia429282e516610fd9ee2677bb930da9e02f6e43a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183750 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2025-02-25use more concrete UNO types in some local varsNoel Grandin1-4/+4
found by a little plugin I created. Change-Id: I5ff1f279c3510dbec2d6b208b09f3cd7f55e75b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182161 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-12-08Simplify ScCellRangesBase and descendantsMike Kaganski1-279/+5
Change-Id: I2416ab8a9263bd7858e0d62055067b3c6132e0b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178093 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-11-28Simplify ScSubTotalParamMike Kaganski1-12/+12
Change-Id: I4c1840e377711ad065c3042bddacb2028481b88d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177433 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-11-24Let ESelection use EPaM for simplificationMike Kaganski1-5/+4
And drop EPosition, which duplicates EPaM, except for its default ctor (used in a single place). Change-Id: I48bb6dafcba84465d61579df0ec71b815945532a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177075 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-11-06cid#1556442 COPY_INSTEAD_OF_MOVECaolán McNamara1-2/+2
and cid#1607753 COPY_INSTEAD_OF_MOVE cid#1554790 COPY_INSTEAD_OF_MOVE cid#1556463 COPY_INSTEAD_OF_MOVE cid#1554838 COPY_INSTEAD_OF_MOVE cid#1556231 COPY_INSTEAD_OF_MOVE cid#1556878 COPY_INSTEAD_OF_MOVE cid#1554913 COPY_INSTEAD_OF_MOVE cid#1558064 COPY_INSTEAD_OF_MOVE cid#1557043 COPY_INSTEAD_OF_MOVE cid#1556985 COPY_INSTEAD_OF_MOVE cid#1556766 COPY_INSTEAD_OF_MOVE cid#1557351 COPY_INSTEAD_OF_MOVE cid#1554863 COPY_INSTEAD_OF_MOVE cid#1556764 COPY_INSTEAD_OF_MOVE cid#1556279 COPY_INSTEAD_OF_MOVE cid#1555970 COPY_INSTEAD_OF_MOVE cid#1556942 COPY_INSTEAD_OF_MOVE cid#1557964 COPY_INSTEAD_OF_MOVE cid#1555166 COPY_INSTEAD_OF_MOVE cid#1556496 COPY_INSTEAD_OF_MOVE cid#1557175 COPY_INSTEAD_OF_MOVE cid#1558054 COPY_INSTEAD_OF_MOVE cid#1557392 COPY_INSTEAD_OF_MOVE cid#1557850 COPY_INSTEAD_OF_MOVE cid#1555118 COPY_INSTEAD_OF_MOVE cid#1557131 COPY_INSTEAD_OF_MOVE cid#1556614 COPY_INSTEAD_OF_MOVE cid#1609650 COPY_INSTEAD_OF_MOVE cid#1555114 COPY_INSTEAD_OF_MOVE cid#1555241 COPY_INSTEAD_OF_MOVE cid#1555442 COPY_INSTEAD_OF_MOVE cid#1556473 COPY_INSTEAD_OF_MOVE cid#1557654 COPY_INSTEAD_OF_MOVE cid#1554689 COPY_INSTEAD_OF_MOVE cid#1556316 COPY_INSTEAD_OF_MOVE cid#1557929 COPY_INSTEAD_OF_MOVE cid#1554807 COPY_INSTEAD_OF_MOVE cid#1554858 COPY_INSTEAD_OF_MOVE cid#1555103 COPY_INSTEAD_OF_MOVE cid#1555517 COPY_INSTEAD_OF_MOVE cid#1556424 COPY_INSTEAD_OF_MOVE cid#1557252 COPY_INSTEAD_OF_MOVE cid#1557566 COPY_INSTEAD_OF_MOVE cid#1608020 COPY_INSTEAD_OF_MOVE cid#1557742 COPY_INSTEAD_OF_MOVE cid#1555884 COPY_INSTEAD_OF_MOVE cid#1554809 COPY_INSTEAD_OF_MOVE cid#1555336 COPY_INSTEAD_OF_MOVE cid#1555173 COPY_INSTEAD_OF_MOVE cid#1556067 COPY_INSTEAD_OF_MOVE cid#1557040 COPY_INSTEAD_OF_MOVE cid#1556235 COPY_INSTEAD_OF_MOVE cid#1557366 COPY_INSTEAD_OF_MOVE cid#1555910 COPY_INSTEAD_OF_MOVE cid#1556716 COPY_INSTEAD_OF_MOVE cid#1558022 COPY_INSTEAD_OF_MOVE cid#1555769 COPY_INSTEAD_OF_MOVE cid#1555940 COPY_INSTEAD_OF_MOVE cid#1557077 COPY_INSTEAD_OF_MOVE cid#1555270 COPY_INSTEAD_OF_MOVE cid#1555660 COPY_INSTEAD_OF_MOVE cid#1556302 COPY_INSTEAD_OF_MOVE cid#1555678 COPY_INSTEAD_OF_MOVE cid#1556538 COPY_INSTEAD_OF_MOVE cid#1557689 COPY_INSTEAD_OF_MOVE cid#1555009 COPY_INSTEAD_OF_MOVE cid#1555433 COPY_INSTEAD_OF_MOVE cid#1555671 COPY_INSTEAD_OF_MOVE cid#1555255 COPY_INSTEAD_OF_MOVE cid#1557681 COPY_INSTEAD_OF_MOVE cid#1557512 COPY_INSTEAD_OF_MOVE cid#1554958 COPY_INSTEAD_OF_MOVE cid#1555758 COPY_INSTEAD_OF_MOVE cid#1555597 COPY_INSTEAD_OF_MOVE cid#1558040 COPY_INSTEAD_OF_MOVE cid#1556476 COPY_INSTEAD_OF_MOVE cid#1557646 COPY_INSTEAD_OF_MOVE cid#1557950 COPY_INSTEAD_OF_MOVE cid#1557019 COPY_INSTEAD_OF_MOVE cid#1557885 COPY_INSTEAD_OF_MOVE cid#1556402 COPY_INSTEAD_OF_MOVE cid#1557906 COPY_INSTEAD_OF_MOVE cid#1556619 COPY_INSTEAD_OF_MOVE cid#1554683 COPY_INSTEAD_OF_MOVE cid#1556549 COPY_INSTEAD_OF_MOVE cid#1554747 COPY_INSTEAD_OF_MOVE cid#1554929 COPY_INSTEAD_OF_MOVE cid#1555362 COPY_INSTEAD_OF_MOVE cid#1557053 COPY_INSTEAD_OF_MOVE cid#1557891 COPY_INSTEAD_OF_MOVE cid#1555043 COPY_INSTEAD_OF_MOVE cid#1555107 COPY_INSTEAD_OF_MOVE cid#1557203 COPY_INSTEAD_OF_MOVE cid#1556728 COPY_INSTEAD_OF_MOVE cid#1557773 COPY_INSTEAD_OF_MOVE cid#1556845 COPY_INSTEAD_OF_MOVE Change-Id: I001fb67e597b096e992fd8a0cd6f3ec577767c33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176098 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-10-28tdf#162262 sc add "Summary below data" option for Subtotal dialogBalazs Varga1-0/+6
With this option we can set where the summary rows should appear, above or below the datas when we create a new Subtotal area. The default option is "True" (which means the summary rows are below the datas) when we create a new subtotal area. Unless if we already have one subtotal area on the same sheet, in that case the sheet level property, "TotalsRowBelow" contains where should the summary rows be for the new Subtotal's. TODO: add new ODF xml attribute for Summary below Change-Id: Icf86c85041d75c24919cb528846d5bb2b517ca78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175556 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-10-25speedup saving large XLS file with lots of query formula(2)Noel Grandin1-2/+1
reduce cost of OUString construction by avoiding initialising a temporary and then overwriting it. 12s to 10s Change-Id: I889152ba71947004ca7d5c96f073182c94d95ed5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175539 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-09-27tdf#160062 Uno API to set solver settings at the sheet levelRafael Lima1-0/+7
This patch creates the API necessary to create solver models via macros, so that the model is visible in the Solver dialog, and the model is saved to the file. This patch also includes a comprehensive unit test in scsolverobj.cxx. Visit the bug ticket for a file with some examples of such macros. Change-Id: Ib9cfbbdaab8243cd6b901a2bcd99e46c27be97e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171769 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-09-04use less dynamic_cast when broadcasting SfxHint in scNoel Grandin1-9/+12
Change-Id: I25ee079b5b14f82012f868ae6b348fa6982571a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172853 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-07-18make ScRange single-arg constructor explicitNoel Grandin1-6/+6
Change-Id: Ie24e1e601b639dd62dbb8a201378a970699b20ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170686 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-06-29Simplify some uses of convertTwipToMm100Mike Kaganski1-4/+2
Change-Id: I073ac7358c1bcb82992ec7746f4b3986d6d35633 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169755 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-19Fix typoAndrea Gelmini1-1/+1
Change-Id: I7ee174497b9f6ca7256ef71297c20c04b52ecae4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169179 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-05-28loplugin:ostr in sc/../unoobjNoel Grandin1-17/+17
Change-Id: I182a5f28c872eb4dd96b930b86b9aef42459f191 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168145 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-02tdf#146619 Remove unused #includes from C/C++ filesRafał Dobrakowski1-1/+0
'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-23Related: tdf#160056 do calc NumberFormatting via ScInterpreterContextCaolán McNamara1-10/+15
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-03-22improve loplugin:staticmethodsNoel Grandin1-2/+2
Some of the exclusions were too aggressive. Restrict them to only the important classes, which exposes some more places this plugin applies. Change-Id: I1b2d1fb24391adc71ed0984f94168f61a149479f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165154 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-21ITEM: Remove InvalidateAllItems()Armin Le Grand (allotropia)1-1/+1
I checked if this is used, but it can be replaced using Clear() -> all. This prevents that the whole array of Items in an ItemSet gets set to INVALID_POOL_ITEM. I also checked if INVALID_POOL_ITEM/IsInvalidItem is needed at all representing SfxItemState::DONTCARE but it is and still will need to be set for individual Items. At last checked if SfxItemState::UNKNOWN and ::DISABLED really need to be separate states, but indeed there are some rare cases that need that. To make things more consistent I also renamed SfxItemState::DONTCARE to SfxItemState::INVALID to better match Set/IsInvalid calls at ItemSet. The build showed a missing UT and led to a problem due to the hand-made ItemSet-like SearchAttrItemList. The state 'invalid' seems to be used as 'unused' marker. It should be changed to use SfxPoolItemHolder and not need that. For now, set by using an own loop to set to that state. Change-Id: Ifc51aad60570569a1e37d3084a5e307eed47d06c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165035 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-12-28Decouple ScPatternAttr from SfxItemPoolArmin Le Grand (allotropia)1-7/+7
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-07ITEM: Get away from classic 'poolable' Item flagArmin Le Grand (allotropia)1-1/+1
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-10-20Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: scStephan Bergmann1-9/+9
Change-Id: Ieed908bfa2cb6370ead922dfc00dbdb4f905f3cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158216 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11Drop o3tl::span, can use C++20 std::span directly nowStephan Bergmann1-1/+1
Change-Id: Ic21ff7bf48f07f7277979d52e99d2c5c268de83f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157825 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-22tdf#146619 Recheck include/c* with IWYUGabor Kelemen1-0/+1
Change-Id: I0cf6f675483bddf82e7347b484a874c71963bfd7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156984 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-09-15reduce casting around ScDocShellNoel Grandin1-2/+1
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-08inline SC_QUERYINTERFACE macrosNoel Grandin1-59/+74
which means we need a few more cppu::queryInterface variants Change-Id: I5cf7805ab9576919bfd66a3b239917e48a7f8f61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156701 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-27sc: import and prop. theme color support for cell bordersTomaž Vajngerl1-48/+6
Adds import for theme colors for cell borders and UNO properties for the cell border theme (complex) colors. Change-Id: I9d8dd7e71f74a623f916e19d59964058f43440bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153502 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-25sc: simplify and fix prop. mapping for cell BG and char theme colorTomaž Vajngerl1-24/+13
Change-Id: I461106200d37f0c605c07095c6b5871ea89e0e20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153501 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-21sc: add CharComplexColor and CellBackgroundComplexColor propertiesTomaž Vajngerl1-0/+13
Change-Id: I30153796a39b2aa3648cb107905974ed6f0f3851 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151668 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-18Use getXWeak in scMike Kaganski1-3/+3
Change-Id: I6a120265be4e4f2ec859a17459d9d92ea23f00d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150863 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-01-23XUnoTunnel->dynamic_cast in ScCellRangesBaseNoel Grandin1-15/+7
Change-Id: Iac62a8ed51d21cc2ef957b3e4811554b62cdb0d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145982 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-23XUnoTunnel->dynamic_cast in ScSubTotalDescriptorBaseNoel Grandin1-1/+1
Change-Id: I45b15bf9a9be2de82b86701cd3af5c4f8c6fff13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145980 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-23XUnoTunnel->dynamic_cast in ScEditFieldObjNoel Grandin1-2/+2
Change-Id: I6bf89f1a6dc3f7bd1c1934e651e235ba572e83c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145979 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-22XUnoTunnel->dynamic_cast in ScTableConditionalFormatNoel Grandin1-1/+1
Change-Id: Ice24bb4e6258b40228213b82436ea6d1d50d0e8e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145975 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-22XUnoTunnel->dynamic_cast in ScTableValidationObjNoel Grandin1-1/+1
Change-Id: I7b42ed7b7d7332c24908d0011a216e9617e6c80d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145974 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-22XUnoTunnel->dynamic_cast in ScCellSearchObjNoel Grandin1-3/+3
Change-Id: I6f2eda6daf92959973d97a4be38f58a11415776f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145973 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-05tdf#150749 Find and replace on very large sheetNoel Grandin1-3/+6
This requires 2 fixes (*) First, we are deleting from the front of a block in the mdds storage, so apply a similar patch to mdds to the previous improvement, (*) Then, we end up with an O(n^2) situation in ScRangesList::Join. But we are only displaying this data, and in fact, we only display the first 1000 ranges anyway, so just clamp the list to 1000 entries, and pass a flag up to the dialog so that we can report that we stopped counting. (*) I had to tweak the testSharedStringPool unit test, since we are not actually clearing the underlying mdds storage, the reference counts do not drop until we have removed all the elements in that block of mdds storage (because then the entire block is destructed, including the not-yet destructed elements) Change-Id: I2c998f81dfb46453a48fce1254fd253d299d12b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139400 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-27sal_uLong->sal_uInt32 in ValidationEntryNoel Grandin1-1/+1
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-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan Bergmann1-1/+1
...so that its TOOLS_WARN_EXCEPTION can be used in comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it, rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The comphelper module is sufficiently low-level for this immediate use case, so use that at least for now; o3tl might be even more suitable but doesn't have a Library until now. Also, for the immediate use case it would have sufficed to only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION, TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of include/tools/diagnose_ex.h into an additional new include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move the complete include file as is.) Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-08-07clang-tidy modernize-pass-by-value in scNoel Grandin1-6/+7
Change-Id: Ia7ff651d1cbc119b36a9f8052594d03650988f59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137848 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-25use more o3tl::spanNoel Grandin1-8/+1
which means we can reserve precisely the right number of entries when building maps Change-Id: I580414699289369de4730caae09829bbd8759e82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137292 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-18create getter for ScCellValue::mpFormulaNoel Grandin1-9/+9
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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-06 23:50:47 +0000