aboutsummaryrefslogtreecommitdiff
path: root/source/kn/sd
ModeNameSize
d---------source64logplain
d---------uiconfig67logplain
ble LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sc/source/core/tool/ddelink.cxx
AgeCommit message (Collapse)Author
2025-01-01tdf#114441 Convert use to sal_uLong to sal_uInt32kkasliwal
Change-Id: I26669ed7a15b27314e97ec29076d07f798a54ba0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179572 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-12-28Decouple ScPatternAttr from SfxItemPoolArmin Le Grand (allotropia)
ScPatternAttr is traditionally derived from SfxPoolItem (or better: SfxSetItem) and held in the ScDocumentPool as Item. This is only because of 'using' the 'poolable' functionality of the Item/ItemSet/ItemPool mechanism. Lots of hacks were added to sc and Item/ItemSet/ ItemPool to make that 'work' which shows already that this relationship is not optimal. It uses DirectPutItemInPool/DirectRemoveItemFromPool to do so, also with massive overhead to do that (and with not much success). The RefCnt in the SfxPoolItem that is used for this never worked reliably, so the SfxItemPool was (ab)used as garbage collector (all Items added and never removed get deleted at last for good when the Pool goes down). For this reasons and to be able to further get ItemSets modernized I changed this. I did two big changes here: (1) No longer derive ScPatternAttr from SfxItemSet/ SfxSetItem, no longer hold as SfxPoolItem (2) Add tooling to reliably control the lifetime of ScPatternAttr instances and ther uniqueness/ reusage for memory reasons It is now a regular non-derived class. The SfxItemSet formally derived from SfxSetItem is now a member. The RefCnt is now also a member (so independent from size/data type of SfxPoolItem). All in all it's pretty much the same size as before. To support handling it I created a CellAttributeHelper that is at/owned by ScDocument and takes over tooling to handle the ScPatternAttr. It supports to guarantee the uniqueness of incarnated ScPatternAttr instances for a ScDocument by providing helpers like registerAndCheck and doUnregister. It hosts the default CellAttribute/ ScPatternAttr. That default handling was anyways not using the standard default-handling of Items/Pools. I adapted whole SC to use that mainly by replacing calls to DirectPutItemInPool with registerAndCheck and DirectRemoveItemFromPool with doUnregister, BUT: This was not sufficient, the RefCnt kept to be broken. For that reason I decided to also do (2) in this change: I added a CellAttributeHolder that owns/regulates the lifetime of a single ScPatternAttr. Originally it also contained the CellAttributeHolder, but after some thoughts I decided that this is not needed - if there is no ScPatternAttr set, no CellAttributeHolder is needed for safe cleanup at destruction of the helper. So I moved/added the CellAttributeHolder to ScPatternAttr where it belongs more naturally anyways. The big plus is that CellAttributeHolder is just one ptr, so not bigger than having a simple ScPatternAttr*. That way, e.g. ScAttrEntry in ScAttrArray did not 'grow' at all. In principle all places where a ScPatternAttr* is used can now be replaced by using a CellAttributeHolder, except for construction. It is capable to be initialized with either ScPatternAttr instances from the heap (it creates a copy that then gets RefCounted) or allocated (it supports ownership change at construction time). Note that ScAttrEntry started to get more a C++ class in that change, it has a constructor. I did not change the SCROW member, but that should also be done. Also made registerAndCheck/doUnregister private in CellAttributeHelper and exclusively used by CellAttributeHolder. That way the RefCnt works, and a lot of code gets much simpler (check ScItemPoolCache, it's now straightforward) and safer and ~ScPatternAttr() uses now a hard assert(!isRegistered()); which shows that RefCnt works now (the 1st time?). There can be done more (see ToDo section below) but I myself will concentrate on getting ItemSets forward. This decoupling makes both involved mechanisms more safe, less complex and more stable. It also opens up possibilities to further optimize ScPatternAttr in SC without further hacking Item/ItemSet/ItemPool stuff. NOTE: ScPatternAttr *should* be renamed to 'CellAttribute' which describes what it is. The experiencd devs may know what it does, but it is a hindrance for understanding for attacting new devs. I already used now names like CellAttributeHelper/CellAttributeHolder etc., but abstained from renaming ScPatternAttr, see ToDo list below. SfxItemSet discussion: ScPatternAttr still contains a SfxItemSet, or better, a SfxSetItem. For that reason it still depends on access to an SfxItemPool (so there is acces in CellAttributeHelper). This is in principle not needed - no Item (in the range [ATTR_PATTERN_START .. ATTR_PATTERN_END]) needs that. In principle ScPatternAttr could now do it's own handling of those needed Items, however this might be done (linear array, hash-by-WhichID, ...). The Items get translated to and from this to the rest of the office anyways. Note that *merging* of SfxItemSets is *still* needed what means to have WhichID slots in SfxItemState::DONTCARE, see note in ScPatternAttr::ScPatternAttr about that. And there is also the Surrogates stuff which would have to be checked. The other extreme is to use SfxItemSet *more*, e.g. directly derive from SfxItemSet what would make stuff easier, maybe even get back to using the 'regular' Items like all office, I doubt that that would be much slower, so why...? Also possible is to remove that range of Items exclusively used by ScPatternAttr from ScDocumentPool *completely* and create an own Pool for them, owned by CellAttributeHelper. That Pool might even be static global, so all SC Docs could share all those Items - maybe even the ScPatternAttr themselves (except the default per document). That would remove the dependency of ScPatternAttr from a Pool completely. ToDo-List: - rename ScPatternAttr to CellAttribute or similar - use SfxItemSetFixed with range [ATTR_PATTERN_START .. ATTR_PATTERN_END] instead of regular SfxItemSet (if the copy-construtor works now...?) - maybe create own/separate Pool for exclusive Items - make ScAttrEntry more a C++ class by moving SCROW to the private section, add get/set methods and adapt SC Had to add some more usages of CellAttributeHolder to the SC Sort mechanism, there were situations where the sorted ScPatternAttr were replaced in the Table, but the 'sorted' ones were just ScPatternAttr*, thus deleting the valid ones in the Table already. Using CellAttributeHolder makes this safe, too. Added a small, one-entry cache to CellAttributeHelper to buffer the last found buffered ScPattrnAttr. It has a HitRate of ca. 5-6% and brings the UnitTest testSheetCellRangeProperties from 0m48,710s to 0m37,556s. Not too massive, but erery bit counts :-) Also shows that after that change optimizations in the now split functionality is possible and easy. Change-Id: I268a7b2a943ce5ddfe3c75b5e648c0f6b0cedb85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161244 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-27Related: tdf#151429 Move fix for tdf#152717 to ScByteSequenceToStringMike Kaganski
The GetString method is only used in DDE context; and allowing it to handle Anys with OUStrings generalizes the fix, simplifying its use. Change-Id: I50952c25fa736a9ca73515801cc1b1903c62453e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147753 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-12-29tdf#152717: ScDdeLink::DataChanged may get OUString directlyMike Kaganski
... after commit 94df17f58fe6269452b7252b712a89978c444bec (tdf#151429: don't convert OUStrings to system encoding, 2022-10-08) Change-Id: Ie9d6eb2a4465a576eefe0840a30636e898fa9028 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144810 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-08-07clang-tidy modernize-pass-by-value in scNoel Grandin
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-05-05use more o3tl::getTokenNoel Grandin
found by inspecting call sites of OUString::getToken Change-Id: I4269c7476c7aa46fac39528227e350568f0eb34a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132644 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-02-14Recheck modules s[a-c]* with IWYUGabor Kelemen
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>
2021-08-13split SvNumberFormatter into it's own headerNoel Grandin
so I can make changes without running into cyclic dependencies between header files Change-Id: I98a91c7cc66002ba745cdb8239e5cc267922a45c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120412 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-26Remove pointless macroGabor Kelemen
DDE_TXT_ENCODING is just an alias since 2008 commit a190965485508c4493ee33228dae68e12cd858f9 and commit cc141699cc6b2fa38b0b0003bff27751e23ae8e4 Change-Id: I2ca32871c13bd3837f173e5f9f959f364857de52 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108330 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-23some places where ScDocument* is never passed a nullptrCaolán McNamara
and so some nullptr checks can be removed Change-Id: I7dedc2c6d054d9749db9766eaa3a5681842b2b69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103239 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2019-03-28tdf#42949 Fix IWYU warnings in include/sfx2/[e-M]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I6e97c7ed6c0211dfafee83b9bdbea672e415fc49 Reviewed-on: https://gerrit.libreoffice.org/69715 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-10-03loplugin:mergeclass merge ScFullMatrix into ScMatrixNoel Grandin
ever since commit b26f83b1cc184a79caa9e9c0ae15717ef61dde4a Date: Fri Aug 10 21:43:32 2018 +0200 loplugin:unusedmethods mostly this seems to be fallout from commit 089a4f245325a5be5cd5951d85305d791b4d9cb6 Date: Mon Aug 6 14:55:04 2018 +0200 remove Calc's software interpreter Change-Id: Id1cb89bb3d95521b7ddf7d072ee9392053e5a52b Reviewed-on: https://gerrit.libreoffice.org/61257 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-01-12More loplugin:cstylecast: scStephan Bergmann
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable loplugin:cstylecast for some more cases" plus solenv/clang-format/reformat-formatted-files Change-Id: I987ac3a6d062600a5e21c3462c70595dfaa51796
2017-12-13tools: remove unused #include from solar.hMichael Stahl
Change-Id: I214e13add371380701ae39403d90a574a63e495d
2017-10-23loplugin:includeform: scStephan Bergmann
Change-Id: I2ed763e0584a188032c80fde60890de3c6985cbd
2017-07-04loplugin:unusedfields in sc part3Noel Grandin
Change-Id: I7323e8644e5d336d52fa21b063264b0847b5e780 Reviewed-on: https://gerrit.libreoffice.org/39064 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-03-03Fix typosAndrea Gelmini
Change-Id: Iedca07be5300c68e180e0c71d2d6eb0052f5cced Reviewed-on: https://gerrit.libreoffice.org/34801 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-02-15Translate German commentsJohnny_M
Change-Id: Ia30dc2f96b34e0edecade84a020092b0a24cbb18 Reviewed-on: https://gerrit.libreoffice.org/33895 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>
2016-12-08convert SFX_HINT to scoped enumNoel Grandin
Notes (*) In SC, BULK_DATACHANGED was or'ed into the hint id. Replaced with a dynamic_cast check. (*) In SC, removed the hint id field from ScIndexHint, no point in storing the hint id twice (*) Fold the SfxStyleSheetHintId enum into the new SfxHintId enum, no point in storing two different hint ids (*) In some cases, multiple #define's used to map to the same SFX_HINT value (notably the SFX_HINT_USER* values). I made all of those separate values. Change-Id: I990e2fb587335ebc51c9005588c6a44f768d9de5 Reviewed-on: https://gerrit.libreoffice.org/31751 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>