aboutsummaryrefslogtreecommitdiff
path: root/source/sq/basctl
diff options
context:
space:
mode:
authorChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2020-09-07 18:01:18 +0200
committerChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2020-09-07 18:08:07 +0200
commit14a72851d401d86cf9fd72a5e139ab87eb0f47d1 (patch)
tree0c6c28e07f4ad7d17bef661296ede6f8430a5b0e /source/sq/basctl
parent6990b2c53807ca4ce972b4c894a5eecc683d67a7 (diff)
update translations for master
and force-fix errors using pocheck Change-Id: I95203f89a4148dd4f91a2a438c5c9811ac2dbe44
Diffstat (limited to 'source/sq/basctl')
-rw-r--r--source/sq/basctl/messages.po120
1 files changed, 99 insertions, 21 deletions
diff --git a/source/sq/basctl/messages.po b/source/sq/basctl/messages.po
index 0df778830ad..7fc38e10ac7 100644
--- a/source/sq/basctl/messages.po
+++ b/source/sq/basctl/messages.po
@@ -3,7 +3,7 @@ msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: https://bugs.libreoffice.org/enter_bug.cgi?product=LibreOffice&bug_status=UNCONFIRMED&component=UI\n"
-"POT-Creation-Date: 2020-08-25 16:09+0200\n"
+"POT-Creation-Date: 2020-09-07 17:17+0200\n"
"PO-Revision-Date: 2017-12-15 09:50+0000\n"
"Last-Translator: Anxhelo Lushka <an_xhelo@hotmail.com>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
@@ -677,44 +677,50 @@ msgctxt "basicmacrodialog|new"
msgid "_New"
msgstr ""
+#. GN5Ft
+#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:415
+msgctxt "basicmacrodialog|extended_tip|new"
+msgid "Creates a new library."
+msgstr ""
+
#. Gh52t
-#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:422
+#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:427
msgctxt "basicmacrodialog|organize"
msgid "Organizer..."
msgstr "Organizuesi..."
#. 3L2hk
-#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:429
+#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:434
msgctxt "basicmacrodialog|extended_tip|organize"
msgid "Opens the Macro Organizer dialog, where you can add, edit, or delete existing macro modules, dialogs, and libraries."
msgstr ""
#. wAJj2
-#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:441
+#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:446
msgctxt "basicmacrodialog|newlibrary"
msgid "New Library"
msgstr "Biblotekë e re"
#. E5rdD
-#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:448
+#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:453
msgctxt "basicmacrodialog|extended_tip|newlibrary"
msgid "Saves the recorded macro in a new library."
msgstr ""
#. 2xdsE
-#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:460
+#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:465
msgctxt "basicmacrodialog|newmodule"
msgid "New Module"
msgstr "Modul i ri"
#. BrAwG
-#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:467
+#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:472
msgctxt "basicmacrodialog|extended_tip|newmodule"
msgid "Saves the recorded macro in a new module."
msgstr ""
#. gMDg9
-#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:515
+#: basctl/uiconfig/basicide/ui/basicmacrodialog.ui:520
msgctxt "basicmacrodialog|extended_tip|BasicMacroDialog"
msgid "Opens a dialog to organize macros."
msgstr ""
@@ -725,18 +731,36 @@ msgctxt "breakpointmenus|manage"
msgid "Manage Breakpoints..."
msgstr "Trajto Pikat Ndërprerëse..."
+#. 2ZNKn
+#: basctl/uiconfig/basicide/ui/breakpointmenus.ui:15
+msgctxt "breakpointmenus|extended_tip|manage"
+msgid "Specifies the options for breakpoints."
+msgstr ""
+
#. faXzj
-#: basctl/uiconfig/basicide/ui/breakpointmenus.ui:23
+#: basctl/uiconfig/basicide/ui/breakpointmenus.ui:28
msgctxt "breakpointmenus|active"
msgid "_Active"
msgstr "_Aktive"
+#. GD2Yz
+#: basctl/uiconfig/basicide/ui/breakpointmenus.ui:32
+msgctxt "breakpointmenus|extended_tip|active"
+msgid "Activates or deactivates the current breakpoint."
+msgstr ""
+
#. FhiYE
-#: basctl/uiconfig/basicide/ui/breakpointmenus.ui:37
+#: basctl/uiconfig/basicide/ui/breakpointmenus.ui:47
msgctxt "breakpointmenus|properties"
msgid "_Properties..."
msgstr "_Vetitë..."
+#. GEknG
+#: basctl/uiconfig/basicide/ui/breakpointmenus.ui:51
+msgctxt "breakpointmenus|extended_tip|properties"
+msgid "Specifies the options for breakpoints."
+msgstr ""
+
#. G55tN
#: basctl/uiconfig/basicide/ui/defaultlanguage.ui:30
msgctxt "defaultlanguage|DefaultLanguageDialog"
@@ -1049,24 +1073,60 @@ msgctxt "managebreakpoints|ManageBreakpointsDialog"
msgid "Manage Breakpoints"
msgstr "Trajto pikat ndërprerëse"
+#. TvBmF
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:40
+msgctxt "managebreakpoints|extended_tip|new"
+msgid "Creates a breakpoint on the line number specified."
+msgstr ""
+
+#. CCDEi
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:60
+msgctxt "managebreakpoints|extended_tip|delete"
+msgid "Deletes the selected breakpoint."
+msgstr ""
+
#. PcuyN
-#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:139
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:146
msgctxt "managebreakpoints|active"
msgid "Active"
msgstr "Aktiv"
+#. fqCCT
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:155
+msgctxt "managebreakpoints|extended_tip|active"
+msgid "Activates or deactivates the current breakpoint."
+msgstr ""
+
+#. MUMSv
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:218
+msgctxt "managebreakpoints|extended_tip|entries"
+msgid "Enter the line number for a new breakpoint, then click New."
+msgstr ""
+
+#. RVBS5
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:245
+msgctxt "managebreakpoints|extended_tip|pass"
+msgid "Specify the number of loops to perform before the breakpoint takes effect."
+msgstr ""
+
#. VDCwR
-#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:237
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:258
msgctxt "managebreakpoints|label2"
msgid "Pass count:"
msgstr "Numërimi i hapave:"
#. 5dExG
-#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:260
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:281
msgctxt "managebreakpoints|label1"
msgid "Breakpoints"
msgstr "Pikat e ndërprerjes"
+#. FGsQQ
+#: basctl/uiconfig/basicide/ui/managebreakpoints.ui:308
+msgctxt "managebreakpoints|extended_tip|ManageBreakpointsDialog"
+msgid "Specifies the options for breakpoints."
+msgstr ""
+
#. M2Sx2
#: basctl/uiconfig/basicide/ui/managelanguages.ui:16
msgctxt "managelanguages|ManageLanguagesDialog"
@@ -1133,50 +1193,68 @@ msgctxt "modulepage|newdialog"
msgid "_New..."
msgstr "_E re..."
+#. AvaAy
+#: basctl/uiconfig/basicide/ui/modulepage.ui:165
+msgctxt "modulepage|extended_tip|newdialog"
+msgid "Lets you manage the macro libraries."
+msgstr ""
+
+#. LeigB
+#: basctl/uiconfig/basicide/ui/modulepage.ui:186
+msgctxt "modulepage|extended_tip|delete"
+msgid "Creates a new macro, or deletes the selected macro."
+msgstr ""
+
#. 5FC8g
-#: basctl/uiconfig/basicide/ui/modulepage.ui:189
+#: basctl/uiconfig/basicide/ui/modulepage.ui:199
msgctxt "modulepage|password"
msgid "_Password..."
msgstr "_Fjalëkalimi..."
#. apZrB
-#: basctl/uiconfig/basicide/ui/modulepage.ui:196
+#: basctl/uiconfig/basicide/ui/modulepage.ui:206
msgctxt "modulepage|extended_tip|password"
msgid "Assigns or edits the password for the selected library."
msgstr ""
#. EgCDE
-#: basctl/uiconfig/basicide/ui/modulepage.ui:208
+#: basctl/uiconfig/basicide/ui/modulepage.ui:218
msgctxt "modulepage|import"
msgid "_Import..."
msgstr "_Importo..."
#. qCXgD
-#: basctl/uiconfig/basicide/ui/modulepage.ui:215
+#: basctl/uiconfig/basicide/ui/modulepage.ui:225
msgctxt "modulepage|extended_tip|import"
msgid "Locate that %PRODUCTNAME Basic library that you want to add to the current list, and then click Open."
msgstr ""
#. GAYBh
-#: basctl/uiconfig/basicide/ui/modulepage.ui:227
+#: basctl/uiconfig/basicide/ui/modulepage.ui:237
msgctxt "modulepage|export"
msgid "_Export..."
msgstr "_Eksporto..."
#. 9Z2WP
-#: basctl/uiconfig/basicide/ui/modulepage.ui:253
+#: basctl/uiconfig/basicide/ui/modulepage.ui:263
msgctxt "modulepage|extended_tip|ModulePage"
msgid "Lists the existing modules or dialogs."
msgstr ""
+#. rCNTN
+#: basctl/uiconfig/basicide/ui/newlibdialog.ui:32
+msgctxt "newlibdialog|extended_tip|ok"
+msgid "Runs or saves the current macro."
+msgstr ""
+
#. Skwd5
-#: basctl/uiconfig/basicide/ui/newlibdialog.ui:86
+#: basctl/uiconfig/basicide/ui/newlibdialog.ui:91
msgctxt "newlibdialog|area"
msgid "_Name:"
msgstr "_Emri:"
#. FWXXE
-#: basctl/uiconfig/basicide/ui/newlibdialog.ui:126
+#: basctl/uiconfig/basicide/ui/newlibdialog.ui:131
msgctxt "newlibdialog|extended_tip|NewLibDialog"
msgid "Enter a name for the new library or module."
msgstr ""
generated by cgit (git 2.34.1) at 2025-01-21 16:50:28 +0000
LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sc/inc/attarray.hxx
AgeCommit message (Collapse)Author
2024-04-02tdf#146619 Remove unused #includes from C/C++ filesRafał Dobrakowski
'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>
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-12-01move the SfxItemPoolCache to sc/Noel Grandin
and rename it to ScItemPoolCache, since its only use is to handle ScPatternAttr objects Change-Id: I68a2dd5f47fcf902f9df552e1a1767d5061d85d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160162 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-07ITEM: Get away from classic 'poolable' Item flagArmin Le Grand (allotropia)
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-11cool#7330 calc perf: PaintTile's FillInfoNoel Grandin
try to spend a little less time here, when searching twice, we can use the index result of the first search as a hint Change-Id: I7fc0c2fb4e5e338d2c3f8a3d642043a1b301e7b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157749 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-25tdf#93315 sc: Only 84 empty row show in the Print PreviewCzeber László Ádám
Change in Calc behaviour, dropping the 84 line limit. This way, if all rows or columns are bordered, only up to the last cell containing data is displayed in the Print Preview. In other cases, all bordered cells are visible. Change-Id: I7d874a093d76d5ed92b1b63b645b97582d52629e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153256 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2022-05-30first arg of ApplyFrame is never nullLuboš Luňák
e4008dc0c3b43c9eacdd88511075be2b88 did this for ApplyBlockFrame() but didn't chagne ApplyFrame() which is only called from there. Change-Id: I9f1dce3dc7fda23b42e90432c13dfca0aa7f267e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135130 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-12don't artificially clamp attribute iterators rangeLuboš Luňák
Even ScDocument::GetDefPattern() can be modified by the user (it's the default style that can be edited), so it's conceptually incorrect to ignore it while iterating, and clamping to allocated columns is also no longer needed. If this makes some code slow, then that needs explicit handling in that code or some other way of speeding things up. Change-Id: I4a7c7fef0a8625b559bbce4580df19a5e9ed92a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132911 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-11load ods/xlsx with full row attributes without allocating all columnsLuboš Luňák
If there's e.g. an entire row bold, it's enough to set default attribute for unallocated columns. This also reverts the workaround from commit 297ab561c6754, as it's no longer necessary. Change-Id: I0b208709aeaff1c0d59da2410926876715cfe642 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131320 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-10fix attr iterators to walk even unallocated columns if neededLuboš Luňák
Things like applying bold to an entire row no longer allocates all rows after my recent changes, but the attribute change is done in ScTable to the default attribute of unallocated columns. That means that clamping column positions to the end of allocated columns is no longer valid when handling attributes. Add functions that clamp depending on whether unallocated columns have a non-default attribute set. Change-Id: I879d0a034c0b336064361d0f8cb12e5a8da22b9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131265 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-08optimize ScTabView::SkipCursorVertical() for many rowsLuboš Luňák
Just like already done for RowHidden(), avoid repeated calls to HasAttrib() and IsVerOverlapped() that would return the same value because it's the same underlying attribute range. Change-Id: Ic270f5ba1333e15d46b5e54e14d9760602221ea7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131151 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-05remove more hardcoded MAXROWLuboš Luňák
Change-Id: Ica57f18d3fd1bf9ec06f05869f4a956d7d1097b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131036 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-07-05store the SfxItemSet inside SfxSetItem by valueNoel Grandin
rather than on the heap, avoiding an allocation Change-Id: I3f1504f9a2d4178a9ba59e98de182a0ab98cdce0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118356 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-23tdf#124176 Use pragma once in s*Vincent LE GARREC
sc, scaddins, sccomp, scripting Change-Id: Ia99fec9e238033821cb784810edd4762c09bd5db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112049 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2020-10-20use tools::Long in scNoel
Change-Id: I8f37a8d1174ed816df971b8cee036d4e88d4a7fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-16ScAttrArray never has a null ScDocument* memberCaolán McNamara
Change-Id: I06e4190235799d6ff231179ae3bbc8f76d4a3342 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102867 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-03-12Revert "loplugin:constfields in sc"Noel Grandin
This reverts commit fb1d3b580763a333bbbfe115d09e1b5cd8849675. Now that we know that making fields has negative side effects like disabling assignment operator generation. Change-Id: Ib48334ffbeb2c768896dd8ced6818aa0b9910b0b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90333 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-26ScPatternAttr needs to be a complete type here (Windows --disable-pch)Stephan Bergmann
Change-Id: Iafbdd3b7e872cd15718879e5c7f1256069156d5f Reviewed-on: https://gerrit.libreoffice.org/71343 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-04-21tdf#81765 slow loading of .ods with >1000 of conditional formats, part 2Noel Grandin
This takes the loading time from 15s to 14s. Reduce unnecessary allocation/copying by passing down ownership of the newly created ScPatternAttr to the item pool Change-Id: Iec38bbff572d10ff8d86f5e65fbe9a96b6a5a706 Reviewed-on: https://gerrit.libreoffice.org/71010 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>