aboutsummaryrefslogtreecommitdiff
path: root/source/ca-valencia/librelogo
AgeCommit message (Expand)Author
2018-01-15update translations after first de-fuzzying roundChristian Lohmaier
2017-12-12resurrect some translated strings via compendiumChristian Lohmaier
2017-04-28update translations for 5.4.0 alpha1Christian Lohmaier
2014-10-17update translations for 4.4.0.0alpha1Christian Lohmaier
2014-05-21update translations for 4.3.0 beta1libreoffice-4-3-branch-pointChristian Lohmaier
2014-04-20update translations for 4.3.0 alpha1Christian Lohmaier
2013-12-09update translations for 4.2.0 Beta2Christian Lohmaier
2013-11-21sync with po-templates for 4.2libreoffice-4-2-branch-pointChristian Lohmaier
2013-09-04renamed translations/source/ca-XV to translations/sourcei/ca-valenciaEike Rathke
generated by cgit (git 2.34.1) at 2025-01-21 17:24:30 +0000
provements2'>feature/template_manager_improvements2 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sc/inc/rangecache.hxx
AgeCommit message (Collapse)Author
2024-06-27Related: tdf#127293 Ignore 'search-criteria-must-apply-to-whole-cell'Balazs Varga
dependency for XLOOKUP and XMATCH because of better compatibility. The idea is to specify, that the global setting 'search-criteria-must-apply-to-whole-cell' is ignored and XMATCH and XLOOKUP always behaves as if 'search-criteria-must-apply-to-whole-cell'=true. That would affect exact search in Match_mode value 0. Users would need to use wildcard or regex to get a match to part of the content. But removing dependency to the global setting increases interoperability with MS Excel. Also the ODF TC will follow that in the final specification of these functions: https://issues.oasis-open.org/browse/OFFICE-4154 Follow-up commit: 17d578ba91f9c78a0e41d19b58183d2214c0b7a4 (Related: tdf#127293 Add new Match_mode option for XLOOKUP and XMATCH functions.) Change-Id: I1317865631d2925eaff72e9c1425d93386c3d016 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169582 Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de> Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Tested-by: Jenkins
2024-05-01Related: tdf#160725 - Add horizontal binary search mode for SortedCacheBalazs Varga
and ScSortedRangeCache classes to support binary search mode in case of different columns. Which is used by the new XLOOKUP function from now on in case of binary search mode. Change-Id: Ibb2ae33670cbe9b47110de57afb6376cd829b465 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166758 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-04-30tdf#160725 - Fix XLOOKUP has different result for approximateBalazs Varga
search than Excel. Some rework for xlookup binary search in rows to get the correct results when we are searching with binary mode in rows. Change-Id: I7ef710c4ae638e2cf5d4bee45810cec7057f5d4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166451 Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de> Tested-by: Jenkins
2022-08-25try harder to ensure InterpretCellsIfNeeded() interprets (tdf#150499)Luboš Luňák
ScFormulaCell::Interpret() tries to interpret the whole formula group (or the given range of it), but it's not guaranteed, and possibly just the called cell will be interpreted. So if a specific range really needs to be interpreted, handle that case. Change-Id: I7fb563ae471eefd49e5bb6c92b6aff98c42a440e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138741 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-06-26fix ByValue lookups with ScSortedRangeCacheLuboš Luňák
My fix for tdf#149071 actually disabled the optimization for all ByValue lookups, because in fact all such lookups have maString set. So lookups where the cells are a mix of numeric and string values need different handling. A simple solution is detecting such a mix when collecting the values for ScSortedRangeCache and disabling the optimization in such a case. But it turns out that queries containing such a mix are not that rare, as documents may e.g. do COUNTIF($C:$C) where the given column has numeric values that start with a textual header. So bail out only if the string cell actually could affect the numeric query. Also fix ScSortedRangeCache usage depending on query parameters, different instances are needed for e.g. different ScQueryOp, because the ScQueryEvaluator functions may return different results (isQueryByString() is automatically true for SC_EQUAL). Change-Id: Ib4565cbf6194e7c525c4d10d00b1c31707952a79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136403 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-06-16share ScSortedRangeCache between threadsLuboš Luňák
It's the same data for all threads, they access it as read-only, so it doesn't make sense for each thread to build its own copy. Change-Id: Ia1559c61d976bcce78661cae7e030bb8430aed7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135794 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11faster reverse mapping in ScSortedRangeCacheLuboš Luňák
Profiling shows this to be a noticeable cost. Change-Id: Ib247a75b77d721f2486a1fe50eb243437d865561 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134127 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11make ScSortedRangeCache work for also ScQueryEntry::ByStringLuboš Luňák
Change-Id: Ifa769e20d91f7899fa81df537a7f3b7aeff52115 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134125 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11introduce Calc cache for sorted handling of unsorted cellsLuboš Luňák
The idea is that there's a cache for a given range, which keeps a vector of SCROW items, sorted by values of those cells. This allows some specific cases of e.g. COUNTIF to simply use BinarySearch() to find the range that matches and work only with that. This commit implements using this cache for COUNTIF. Change-Id: I5b36b289b4aecb3b8245bbb447fbb299371262e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134120 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>