summaryrefslogtreecommitdiff
path: root/sc/source/ui/unoobj/cellsuno.cxx
AgeCommit message (Collapse)AuthorFilesLines
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>
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-16make meType in ScCellValue privateNoel Grandin1-7/+7
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-06-14Related: tdf#149325 Fix yet another VbaRange empty ScRangeList accessEike Rathke1-1/+3
Change-Id: If2c44795ab794482b841138bdd55f37c4d30b592 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135824 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-06-01pass ScRange around by valueNoel Grandin1-19/+18
it's a very small object, and trivially movable. No need to allocate it separately Change-Id: I0adf947433e73a425f39004297c450a93ac4e5f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135216 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-22pass ScDocShell by reference in ctor to indicate never initially nullCaolán McNamara1-1/+1
Change-Id: I6b07f734aba06a643b6240562bb3e427e5c1e9ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134729 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-20new loplugin:unnecessary lockingNoel Grandin1-3/+0
off by default, since each warning needs careful inspection Change-Id: I805c1d1cdde531a1afdc76e87b22f879fc3c9753 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134641 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-18no need to take a lock when returning static dataNoel Grandin1-4/+0
Change-Id: I8d836c4a919056e8b600549f82b0d5dee9ab1a47 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134536 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-04Just use Any ctor instead of makeAny in scStephan Bergmann1-7/+7
Change-Id: I5c2363ff03ae02274f3c334cc262977c834950d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133788 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-12bail out of the loop when the item is foundLuboš Luňák1-4/+3
Change-Id: If0816f38eeeb3330738ab40bc8a72f1e14575c33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132904 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-03make ScMarkData::IsAllMarked() work also for simple marksLuboš Luňák1-4/+0
Change-Id: I41009c83827619605b4cfc4909f1d9922cde68a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130923 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-02-10replace various sal_uLong that might overflow with huge sheetsLuboš Luňák1-1/+1
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>
2022-01-29used TypedWhichId in the constructor of various svx *Item classesNoel Grandin1-1/+1
to act as an extra check that we have the association of Item and TypedWhichId annotations correct. (*) requires that I add an upcasting constructor to TypedWhichId (*) Make the field dialog stuff in writer use a new item id FN_FIELD_DIALOG_DOC_PROPS instead of abusing the existing SID_DOCINFO Change-Id: Ica4aea930c80124609a063768c9af5a189df1c27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129098 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-01-12tdf#146454 - Check for multiline string in setDataArrayAndreas Heinisch1-2/+14
Check for a multiline string in the setDataArray function. If that is the case, set a string or edit cell. Otherwise, just set a plain string in order to prevent performance issues due to the adjustments of the row height. Regression from b9e2c5d2a36fbd189c20448cadf4212edf02914d Change-Id: I9216b198b878fda5da29596d25504db853acd756 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127660 Tested-by: Jenkins Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
2021-12-06rename In() to Contains()Luboš Luňák1-1/+1
Similarly to b22d4785310eac35696d, 'A.In(B)' makes it unclear whether the check is for A in B or B in A, as it's actually the latter. Change-Id: Iaccc41d40f4bb105a44c1bb8d9211c06d1a3c127 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126392 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-12-04loplugin:stringliteraldefine in scNoel Grandin1-620/+620
Change-Id: I49159fa9b525ced9423c9a37d8a31b15cc8b1e98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126308 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-01loplugin:stringliteraldefine in editengNoel Grandin1-1/+1
Change-Id: Ie8f4c338f1636945f61ec139706353df88a81087 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126171 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-11Drop ScGlobal::GetEmptyOUString() and EMPTY_OUSTRINGMike Kaganski1-4/+4
OUString default ctor already uses a static instance (through rtl_uString_new), no need to have another module-specific static. Commit d8037ae18a297229d1b79f8f76331abfd548350d had removed its sw counterpart some time ago. Change-Id: I140fe13bc1f6b0cbe188e83e602fdebe995e467a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125061 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-08tdf#142033 - Handle embedded newline set via SetDataArrayAndreas Heinisch1-3/+2
Change-Id: I798f9a2a2ce599ba8ca3ef1f5ae91801d8f1b138 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124681 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2021-11-08make a number of Calc functions return value by actually returning itLuboš Luňák1-7/+4
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-15Remove non-const Sequence::begin()/end() in internal codeMike Kaganski1-1/+1
... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-14use std::vector::insert instead of push_backNoel Grandin1-2/+1
because it will pre-allocate space and often is optimised to memcpy Change-Id: I03ed7915f2762d3d27e378638052a47a28bbf096 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123588 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-12Pass rDetails argument from getCellRangeByName() to MakeRangeFromName()Eike Rathke1-2/+2
The default MakeRangeFromName() argument ScAddress::detailsOOOa1 is the same as the only call to this getCellRangeByName(), just make it explicit to clarify. Change-Id: I8eb550df95e6332a459cb9946e7c753887a1655a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123452 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
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-18 00:33:41 +0000