aboutsummaryrefslogtreecommitdiff
path: root/source/gl/starmath
ModeNameSize
-rw-r--r--messages.po89033logplain
generated by cgit (git 2.34.1) at 2025-01-15 10:26:18 +0000
n> LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sc/source/filter/excel/xehelper.cxx
AgeCommit message (Collapse)Author
2024-11-24Let ESelection use EPaM for simplificationMike Kaganski
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-10com::sun::star -> cssMike Kaganski
Change-Id: I890ec73e30d3cc6b210903ecee29431f3cb5f635 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175979 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-10-19tdf#158460 xls/x export: don't force wrap-text for imported single-lineJustin Luth
Starting in LO 24.2, we started displaying imported XLS/X files that had contents-with-newlines on a single line if the cell did not have the wrap-text property - just like buggy Excel. So, now we need to round-trip that without setting wrap-text, so that we can continue to exhibit buggy behaviour (instead of fixing the document so that the newlines aren't ignored). A previous attempt to do this was reverted (for many reasons), significantly because it failed to handle the situation where a user entered new newline content (without forcing wrap-text). So in LO the new content DISPLAYS on multiple lines, but after a round-trip it was all squashed together. So it is important to keep the traditional behaviour of forcing wrap-text, and ONLY avoiding it when round-tripping imported content. It also preserves ODS -> XLS/X conversions. I also took the opportunity to rename mbWrapped. make CppunitTest_sc_subsequent_export_test3 \ CPPUNIT_TEST_NAME=testPreserveTextWhitespace2XLSX Change-Id: Ia35b0679946b51626fabd4043779c1b43cc1ae37 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174436 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2024-07-31cid#1555417 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1555423 COPY_INSTEAD_OF_MOVE cid#1555430 COPY_INSTEAD_OF_MOVE cid#1555436 COPY_INSTEAD_OF_MOVE cid#1555440 COPY_INSTEAD_OF_MOVE cid#1555443 COPY_INSTEAD_OF_MOVE cid#1555454 COPY_INSTEAD_OF_MOVE cid#1555459 COPY_INSTEAD_OF_MOVE cid#1555461 COPY_INSTEAD_OF_MOVE cid#1555468 COPY_INSTEAD_OF_MOVE cid#1555477 COPY_INSTEAD_OF_MOVE cid#1555484 COPY_INSTEAD_OF_MOVE cid#1555511 COPY_INSTEAD_OF_MOVE cid#1555515 COPY_INSTEAD_OF_MOVE cid#1555519 COPY_INSTEAD_OF_MOVE cid#1555534 COPY_INSTEAD_OF_MOVE cid#1555537 COPY_INSTEAD_OF_MOVE cid#1555544 COPY_INSTEAD_OF_MOVE cid#1555553 COPY_INSTEAD_OF_MOVE cid#1555559 COPY_INSTEAD_OF_MOVE cid#1555561 COPY_INSTEAD_OF_MOVE cid#1555563 COPY_INSTEAD_OF_MOVE cid#1555564 COPY_INSTEAD_OF_MOVE cid#1555568 COPY_INSTEAD_OF_MOVE cid#1555571 COPY_INSTEAD_OF_MOVE cid#1555580 COPY_INSTEAD_OF_MOVE Change-Id: Ia42a78bffddc80d0e82144f4db51dc6e4d2e9a1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171237 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
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-09-15reduce casting around ScDocShellNoel Grandin
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-06-29sc: use ComplexColor for font color (+others) in OOXML exportTomaž Vajngerl
Change-Id: I2544c7ece152323d84faafe1a544e4f89ca466d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152014 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-26convert ScAutoFontColorMode to scoped enumNoel Grandin
Change-Id: Id34bac78719943bd4c4cbfa60e0cb86b4ca570f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153562 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-22sc: factor out color from setting vcl::Font from a ItemSetTomaž Vajngerl
vcl::Font color parameter is deprecated so we need to handle the color separately from font data. This refactors GetFont into 2 separate functions - fillFontOnly and fillColor, where fillFont now does the same as previously GetFont function did. All GetFont calls have been changed depending on if we need only the font data or also color - where the color is now treated in a different call. There are a couple of calls where fillFont was used, because to change that needs a more complex refactoring. Change-Id: I0a2ce50a0cb28d196fcff87e1e80099a2bb60a9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151858 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-03-18loplugin:stringadd use more O[U]StringCharNoel Grandin
Change-Id: I196e4539ad430a39415eff9d7170b33df7228230 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149062 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-30tdf#90299 Fix saving external links as relativeŁukasz Leszko
In current build some links to external xls files are not saved as relative even if "Save URLs relative to file system" option is checked. This patch aims to solve this issue. Change-Id: I6d0984bdcdeef57b227c8ab1353e002fa4355fc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131711 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-08-25These are DOS paths, not URLsMike Kaganski
Change-Id: I851120db13d84f7a48e4cbbbf8f9dca14ed6e61d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138801 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-06-03elide some makeStringAndClear() classNoel Grandin
when we are passing the result to a string_view, it is pointless. Change-Id: I5af990cbe1a8f2d5b19fea9a031d7d64aeba1c37 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135329 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-29use more string_view in INetURLObjectNoel Grandin
Change-Id: I4462f7cf4740fa4d1b129d76a0775f4250f41bbd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133555 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-18tdf#133603 remove some string copyingNoel Grandin
Change-Id: I5b9f011d276ec30a50648e7984862b9e5f4b5577 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131729 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-01use SfxItemSet::GetItemIfSet in sc/source/filterNoel Grandin
Change-Id: I8ba941cea8f3b8ed0f37d2dc6b2520ae89652afe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130744 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-11Drop ScGlobal::GetEmptyOUString() and EMPTY_OUSTRINGMike Kaganski
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-10-07use SfxItemSetFixed in scNoel Grandin
Change-Id: I5b1d66adb1b9e5dd0e470403ba7095183334cc66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123182 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-02rename UpdateMode -> UpdateLayout in editeng classNoel Grandin
... because "update" is such a generic term I keep forgetting what we are turning on and off Also return the previous value from SetUpdateLayout to make the save/restore code more compact. Change-Id: Iae1764c837a92e58c9b17521f130e8fc80311d22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121479 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-19Move svl::Items to include/svl/whichranges.hxx, and unify its usageMike Kaganski
... in WhichRangesContainer and SfxItemSet ctors. Now it's not needed to explicitly use 'value' in WhichRangesContainer's ctor, or create an instance for use in SfxItemSet ctor (svl::Items is already defined as a template value of corresponding type). Instead of WhichRangesContainer Foo(svl::Items<1, 2>::value); SfxItemSet Bar(rItemPool, svl::Items<1, 2>{}); now use: WhichRangesContainer Foo(svl::Items<1, 2>); SfxItemSet Bar(rItemPool, svl::Items<1, 2>); Change-Id: I4681d952b6442732025e5a26768098878907a238 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119157 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-05-03loplugin:stringadd improvement for appending numbersNoel Grandin
I was wrong, the Concat framework already optimised appending numbers by stack-allocating small buffers, so include them in the plugin Change-Id: I922edbdde273c89abfe21d51c5d25dc01c97db25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115037 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-27loplugin:stringadd convert chained append to +Noel Grandin
which can use the more efficient *StringConcat Also fix a crash in stringview plugin which started happening while I working on this. Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-22no need to create temporaries when appending number to O[U]StringBufferNoel Grandin
Change-Id: I36d82423b5f75010552696a66cec7e53ee265ce4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114395 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-28simplify code, use more subView()Noel
Change-Id: I569c7f34acbdf8451cd5c9acf1abd334637072d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110051 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-12New loplugin:stringviewparamStephan Bergmann
...to "Find functions that take rtl::O[U]String parameters that can be generalized to take std::[u16]string_view instead." (Which in turn can avoid costly O[U]String constructions, see e.g. loplugin:stringview and subView.) Some of those functions' call sites, passing plain char string literals, needed to be adapted when converting them. Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-19Fix typosAndrea Gelmini
Change-Id: Ibe3cd52117f7f47e1806bde76114cb1644d78763 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100969 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-07-17tdf#134817 XLSX export: fix partially lost header/footerAttila Szűcs
When header/footer text contain text portions with different font setting, only the last text portion was exported. Co-authored-by: Tibor Nagy (NISZ) Change-Id: Id4cba2b9188459cdaa0ade30c2217d8f59fe6316 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98938 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-07-17tdf#134459 XLSX export: fix missing font color in header/footerAttila Szűcs
Co-authored-by: Tibor Nagy (NISZ) Change-Id: I7aacbad1c4052b2480630d0b98175b46cf2aeed0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98873 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-25convert excel filter in calc from shared_ptr to rtl::ReferenceNoel Grandin
ref-counting traffic here accounts for 10% of the profile on some of my calc imports. Change-Id: I1b32e0e61d7bf5eb65780ec0e7fcb99f6576050a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92694 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>