summaryrefslogtreecommitdiff
path: root/sc
AgeCommit message (Collapse)Author
2022-05-17tdf#123877 sc XLSX: don't freeze during saving recoveryLászló Németh
file by asking password re-typing unstoppably. Instead of this, skip recovery file saving, if the document contains password hashes which haven't been supported by the "calc8" filter of the recovery file (which triggered the "Re-type password" dialog). Solved problems: – Asking for passwords during a non-interactive background process. – A single Cancel didn't close the "Re-type password" dialog window, only pressing three times at least (according to the value of RETRY_STORE_ON_MIGHT_FULL_DISC_USEFULL), but waiting for the password for a while could result a frozen "Re-type password" dialog, where only retyping or removing the password(s) were the escape routes. – Re-typing the password required the password (but modifying the original document doesn't require this). – Removing the password resulted in loss of the protection after saving the original XLSX document. Add a UI test to keep the "Re-type password" dialog during Save As. Note: because of the regression reported in tdf#145757, it needs to wait 10 min for saving the recovery file, yet, despite the changed time in Tools->Options->Load/Save->General. Change-Id: Icc6ee4d67048cdf15ab75ef8e2ee8f1709cdd4c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134409 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2022-05-17At least make CppunitTest_sc_text_functions_test more resilient to ICU versionStephan Bergmann
61f4250ee9f43902107e4d2e6322cbf54f52dd8e "Make CLEAN fully compliant woth ODFF v1.3" has changed lcl_ScInterpreter_IsPrintable (sc/source/core/tool/interpr1.cxx) to use ICU's u_isdefined to check for Unicode code points of category Cn (i.e., noncharacter or reserved). This is at least questionable, as assignment of code points to that category varies with Unicode versions. And while <https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part4-formula/OpenDocument-v1.3-os-part4-formula.html#__RefHeading__1017856_715980110> "Open Document Format for Office Applications (OpenDocument) Version 1.3. Part 4: Recalculated Formula (OpenFormula) Format: 1.4 Normative References" references "The Unicode Standard, Version 5.2.0" (so one might expect CLEAN to use the category classification from that old Unicode version), versions of ICU keep being updated with current Unicode versions' category classifications. For example, the currently bundled external/icu's icu4c-70_1-src.tgz uses Unicode 14 (according to <https://icu.unicode.org/download/70#h.x1orhyniml8k>) for its implementation of u_isdefined. And for --with-system-icu, all that configure.ac apparently requires is that "icu-i18n >= 4.6" (i.e., it will potentially allow the behavior of u_isdefined to vary over a wide range of Unicode versions). And case in point, 61f4250ee9f43902107e4d2e6322cbf54f52dd8e also added a test to sc/qa/unit/data/functions/text/fods/clean.fods (row 47) that verifies that U+FDCF ARABIC LIGATURE SALAAMUHU ALAYNAA does not get cleaned away by CLEAN. But U+FDCF is only an assigned code point (thus no longer of category Cn) since Unicode 14 (cf. <https://www.unicode.org/charts/PDF/Unicode-14.0/U140-FB50.pdf>), so while builds against external/icu (covering Unicode 14) succeed, --with-system-icu builds like a flatpak build against org.freedesktop.Sdk//21.08, still at ICU 69 and Unicode 13, fail CppunitTest_sc_text_functions_test with > Testing load file:///run/build/libreoffice//sc/qa/unit/data/functions/text/fods/clean.fods: > /run/build/libreoffice/sc/qa/unit/functions_test.cxx:43:TextFunctionsTest::testTextFormulasFODS > double equality assertion failed > - Expected: 1 > - Actual : 0 > - Delta : 1e-14 (<https://flathub.org/builds/#/builders/11/builds/7103>). Irrespective of whether using ICU's varying u_isdefined in the implementation of CLEAN is correct, at least make that "doesn't get CLEAN'ed away" test more resilient to what version of ICU is being used, by using F+UF00 TIBETIAN SYLLABLE OM, which got added all the way back in Unicode 2, rather than U+FDCF ARABIC LIGATURE SALAAMUHU ALAYNAA, which only got added in Unicode 14. (And to add insult to injury, in sc/qa/unit/data/functions/text/fods/clean.fods 61f4250ee9f43902107e4d2e6322cbf54f52dd8e encoded U+FDCF in text not as the three UTF-8 bytes 0xEF 0xB7 0x8F, but rather re-encoded as the six bytes 0xC3 0xAF 0xC2 0xB7 0xC2 0x8F, i.e., the three characters U+00EF LATIN SMALL LETTER I WITH DIARESIS, U+00B7 MIDDLE DOT, U+008F. But I assume that was just a mistake, not something that I should faithfully copy in the file's new version.) Change-Id: Icc8d879b1397d8292914cbd31708d0c561f3b06e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134474 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-17freeze() and thaw() a widget during creation (tdf#149112)Luboš Luňák
The repeated inserts each trigger SvTreeList::GetVisibleCount(), which has a poor performance because of repeated uses of the SvListView::Impl::m_DataTable map. Change-Id: Ibb261a8501a1d5c168b37675e34498386f161595 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134415 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-17tdf#142635: use the same ScDocument for clipboard and GlobalDrawPersistMike Kaganski
This way, the document used for chart copy has the proper sheets, and the data ranges are created correctly. This reverts commit 8d98dd8b3896c14af057e90e3a327172a9262e03 Author Mike Kaganski <mike.kaganski@collabora.com> Date Thu Jun 03 13:15:11 2021 +0200 tdf#142635: skip UITest for now Change-Id: I0a3aa6028f49ded278f8665556007b1f722e21b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134251 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-17Related: tdf#142635 Make ScDocShell reference ScDocument by shared_ptrMike Kaganski
Required for eventual sharing of the document between the shell and other pieces having different lifetime, as required to fix tdf#142635. Change-Id: I9e69bd2e3b57d7712526f51161e7e725d4af8068 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134383 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-16Fix a UITest on WindowsMike Kaganski
Change-Id: If4e5612e2b9fa41c487a6ab54c1e23fd2d63ac9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134365 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-16de-lint the .ui file for auto gtk3->gtk4 conversionCaolán McNamara
Change-Id: Icb288ae13e75784e7b560101f33b8a96935bda36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134389 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-16forcepoint#97 avoid Invalid read of size 2Caolán McNamara
==143282== Invalid read of size 2 ==143282== at 0x190CDBFC: SfxItemSet::Count() const (itemset.hxx:96) ==143282== by 0x1910F33E: SfxItemSet::Get(unsigned short, bool) const (itemset.cxx:748) ==143282== by 0x1F14D76C: ScPatternAttr::GetItem(unsigned short, SfxItemSet const&, SfxItemSet const*) (patattr.cxx:1347) ==143282== by 0x1F14D7DA: ScPatternAttr::GetItem(unsigned short, SfxItemSet const*) const (patattr.cxx:1352) ==143282== by 0x202A3E44: ScLineBreakCell const& ScPatternAttr::GetItem<ScLineBreakCell>(TypedWhichId<ScLineBreakCell>, SfxItemSet const*) const (patattr.hxx:83) ==143282== by 0x2028E8BC: ScOutputData::LayoutStrings(bool, bool, ScAddress const&) (output2.cxx:1677) ==143282== by 0x2028D4A8: ScOutputData::DrawStrings(bool) (output2.cxx:1473) ==143282== by 0x202D9879: ScPrintFunc::PrintArea(short, int, short, int, long, long, bool, bool, bool, bool) (printfun.cxx:1675) ==143282== by 0x202DD459: ScPrintFunc::PrintPage(long, short, int, short, int, bool, ScPreviewLocationData*) (printfun.cxx:2301) ==143282== by 0x202DF491: ScPrintFunc::DoPrint(MultiSelection const&, long, long, bool, ScPreviewLocationData*) (printfun.cxx:2713) ==143282== by 0x20031888: ScModelObj::render(int, com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (docuno.cxx:2259) ==143282== by 0x30C1A485: PDFExport::ExportSelection(vcl::PDFWriter&, com::sun::star::uno::Reference<com::sun::star::view::XRenderable> const&, com::sun::star::uno::Any const&, StringRangeEnumerator const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, int) (pdfexport.cxx:219) ==143282== by 0x30C1F879: PDFExport::Export(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (pdfexport.cxx:987) ==143282== by 0x30C33BA2: PDFFilter::implExport(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (pdffilter.cxx:174) ==143282== by 0x30C33F2A: PDFFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (pdffilter.cxx:237) ==143282== by 0x21AC6986: SfxObjectShell::ExportTo(SfxMedium&) (objstor.cxx:2488) ==143282== by 0x21AC2363: SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) (objstor.cxx:1553) ==143282== by 0x21ACE816: SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString const&, rtl::OUString const&, SfxItemSet const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (objstor.cxx:2966) ==143282== by 0x21ACCA87: SfxObjectShell::CommonSaveAs_Impl(INetURLObject const&, rtl::OUString const&, SfxItemSet&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (objstor.cxx:2756) ==143282== by 0x21AA8CDB: SfxObjectShell::APISaveAs_Impl(rtl::OUString const&, SfxItemSet&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (objserv.cxx:317) ==143282== by 0x21B2B4AD: SfxBaseModel::impl_store(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, bool) (sfxbasemodel.cxx:3132) ==143282== by 0x21B2CB12: SfxBaseModel::storeToURL(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (sfxbasemodel.cxx:1768) ==143282== by 0x1C507AFE: ScPDFExportTest::exportToPDF(com::sun::star::uno::Reference<com::sun::star::frame::XModel> const&, ScRange const&) (scpdfexport.cxx:192) ==143282== by 0x1C511A33: ScPDFExportTest::testForcepoint97() (scpdfexport.cxx:571) ==143282== by 0x1C52778D: void std::__invoke_impl<void, void (ScPDFExportTest::*&)(), ScPDFExportTest*&>(std::__invoke_memfun_deref, void (ScPDFExportTest::*&)(), ScPDFExportTest*&) (invoke.h:74) ==143282== by 0x1C5276C1: std::__invoke_result<void (ScPDFExportTest::*&)(), ScPDFExportTest*&>::type std::__invoke<void (ScPDFExportTest::*&)(), ScPDFExportTest*&>(void (ScPDFExportTest::*&)(), ScPDFExportTest*&) (invoke.h:96) ==143282== by 0x1C527659: void std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==143282== by 0x1C5275E2: void std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>::operator()<, void>() (functional:503) ==143282== by 0x1C52758C: void std::__invoke_impl<void, std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&>(std::__invoke_other, std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&) (invoke.h:61) ==143282== by 0x1C52753C: std::enable_if<is_invocable_r_v<void, std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&>, void>::type std::__invoke_r<void, std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&>(std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()>&) (invoke.h:111) ==143282== by 0x1C52731C: std::_Function_handler<void (), std::_Bind<void (ScPDFExportTest::*(ScPDFExportTest*))()> >::_M_invoke(std::_Any_data const&) (std_function.h:290) ==143282== by 0x1C527A34: std::function<void ()>::operator()() const (std_function.h:590) ==143282== by 0x1C527078: CppUnit::TestCaller<ScPDFExportTest>::runTest() (TestCaller.h:175) ==143282== by 0x49326F2: CppUnit::TestCaseMethodFunctor::operator()() const (TestCase.cpp:32) ==143282== by 0x15937E3D: (anonymous namespace)::Protector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (vclbootstrapprotector.cxx:46) ==143282== by 0x4929ED1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20) ==143282== by 0x4B05D6D: (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (unobootstrapprotector.cxx:78) ==143282== by 0x4929ED1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20) ==143282== by 0x4AF2F2A: (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (unoexceptionprotector.cxx:62) ==143282== by 0x4929ED1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20) ==143282== by 0x491261E: CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (DefaultProtector.cpp:15) ==143282== by 0x4929ED1: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20) ==143282== by 0x4928690: CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (ProtectorChain.cpp:86) ==143282== by 0x4946ACD: CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (TestResult.cpp:182) ==143282== by 0x4932103: CppUnit::TestCase::run(CppUnit::TestResult*) (TestCase.cpp:91) ==143282== by 0x4932BCF: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64) ==143282== by 0x4932A5F: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23) ==143282== by 0x4932BCF: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64) ==143282== by 0x4932A5F: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23) ==143282== by 0x494FDBF: CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) (TestRunner.cpp:47) ==143282== Address 0x1d7624b0 is 64 bytes inside a block of size 120 free'd ==143282== at 0x4847669: operator delete(void*) (vg_replace_malloc.c:923) ==143282== by 0x1F150EA1: ScPatternAttr::~ScPatternAttr() (patattr.hxx:53) ==143282== by 0x190D29B2: SfxItemPool::Remove(SfxPoolItem const&) (itempool.cxx:802) ==143282== by 0x1EA27F8E: ScAttrArray::SetPatternAreaImpl(int, int, ScPatternAttr const*, bool, ScEditDataArray*, bool) (attarray.cxx:574) ==143282== by 0x1EBF43D5: ScAttrArray::SetPattern(int, ScPatternAttr const*, bool) (attarray.hxx:148) ==143282== by 0x1EBD9068: ScColumn::ApplyAttr(int, SfxPoolItem const&) (column.cxx:634) ==143282== by 0x1EC6C1EB: ScColumn::SetNumberFormat(int, unsigned int) (column2.cxx:3094) ==143282== by 0x1F1CB737: ScTable::SetNumberFormat(short, int, unsigned int) (table2.cxx:2238) ==143282== by 0x1EE3F135: ScDocument::SetNumberFormat(ScAddress const&, unsigned int) (document.cxx:3717) ==143282== by 0x1F09CCA5: ScFormulaCell::InterpretTail(ScInterpreterContext&, ScFormulaCell::ScInterpretTailParameter) (formulacell.cxx:2155) ==143282== by 0x1F099D9F: ScFormulaCell::Interpret(int, int) (formulacell.cxx:1615) ==143282== by 0x1ECC048D: ScFormulaCell::MaybeInterpret() (formulacell.hxx:465) ==143282== by 0x1F09F5C8: ScFormulaCell::IsValue() (formulacell.cxx:2760) ==143282== by 0x1EA82355: (anonymous namespace)::hasNumericImpl(CellType, ScFormulaCell*) (cellvalue.cxx:155) ==143282== by 0x1EA822FA: ScRefCellValue::hasNumeric() const (cellvalue.cxx:624) ==143282== by 0x2028E876: ScOutputData::LayoutStrings(bool, bool, ScAddress const&) (output2.cxx:1676) ==143282== by 0x2028D4A8: ScOutputData::DrawStrings(bool) (output2.cxx:1473) ==143282== by 0x202D9879: ScPrintFunc::PrintArea(short, int, short, int, long, long, bool, bool, bool, bool) (printfun.cxx:1675) ==143282== by 0x202DD459: ScPrintFunc::PrintPage(long, short, int, short, int, bool, ScPreviewLocationData*) (printfun.cxx:2301) ==143282== by 0x202DF491: ScPrintFunc::DoPrint(MultiSelection const&, long, long, bool, ScPreviewLocationData*) (printfun.cxx:2713) ==143282== by 0x20031888: ScModelObj::render(int, com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (docuno.cxx:2259) ==143282== by 0x30C1A485: PDFExport::ExportSelection(vcl::PDFWriter&, com::sun::star::uno::Reference<com::sun::star::view::XRenderable> const&, com::sun::star::uno::Any const&, StringRangeEnumerator const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, int) (pdfexport.cxx:219) Change-Id: Idf19b79f5aef7e07666249f5f9ec510003a3f886 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132431 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2022-05-16Unfriend someMike Kaganski
Change-Id: Ib0a87bae89903f9ae851a6e3e2d6ef9f9197cf13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134360 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-16fix GETPIVOTDATA() field name lookupLuboš Luňák
Field names are case-insensitive, so the lookup was failing if the name wasn't typed in a way that matched exactly as case-sensitive. The A29 field in getpivotdata.fods test was passing only because the fields were typed in the same order as present in the pivot table, and std::sort() was accidentally stable. But reordering the fields in the formula makes it fail, and so does using libc++ with debug mode (which randomizes equal fields in std::sort()). Change-Id: I88d078da435685c3557f24dc5f4a0bfc4d563aa6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134336 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-15tdf#124820 sc: overwrite more character level font attributesJustin Luth
The issue here is that certain character properties applied at the cell level did not clear out those properties from the character runs. Specifically strikethrough, underline, overline, italics, outline, shadow. Specifically for xlsx import - where a default value is specified in many cases instead of not being defined at all - this meant that the cell change had no real effect, since the direct properties have priority. A 2010 commit 4ef978de83610b0e1912bce1d59432b9c382b9fc did this for font, size, bold, and color. Perhaps that was all that was needed at that time, although even back these other properties probably should have been handled as well, because the cell-change didn't affect the entire contents. In 2013 a LO 4.1 commit f54ce3e7f6d6aab7e34c54ad8eff06650e076fef increased the impact during xlsx import. I assume that adding the CTL/CJK attributes is also necessary. Change-Id: Id933af1ce187a79851868a6a295b33758062fe3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134254 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2022-05-15no ScSortedRangeCache-based query for number-as-string (tdf#149071)Luboš Luňák
The comparison depends on the cell encountered, which makes it hard to prepare the sorted data. Change-Id: I22f55003acde7eedadb8a4c8d61390dd30b6ac8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134287 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-15ScSortedRangeCache-based query doesn't work with mbRangeLookupLuboš Luňák
Change-Id: I9ce8e3547fc261e92e1330df4c054c3efe532d61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134286 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-14Fix typoAndrea Gelmini
Change-Id: I1454a649ab434fe4d34a181bc572472a2784c1df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134321 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-05-13make ScSortedRangeCache-based queries work with mbMatchEmptyLuboš Luňák
Change-Id: Ifc8195222568184dc4f337b23f00e315e22febe2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134218 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-13CppunitTest_sc_uicalc: simplify code a bitXisco Fauli
Change-Id: I65f32c3f308f7ac9a416026efaf0648ff6457ddc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134272 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-05-13tdf#148863: sc_uicalc: Add unittestXisco Fauli
Change-Id: I15e692ed42445821e8fa65c955916c43f58072e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134271 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-05-13add SvStream::ReadLine(OStringBuffer... to reduce OString allocationNoel Grandin
and use it where possible Change-Id: I3efc7a642f73661ce606c917c0323ba9948521c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134265 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-13Use interpreter stack to determine JumpMatrix context, tdf#148863 follow-upEike Rathke
pJumpMatrix may or may not be set; actually may need some rework, but get this straight here. Change-Id: I0948e6aeb6637e7a5009a17f63f01d0733c0205c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134252 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-05-12Resolves: tdf#148863 In JumpMatrix context use its dimensions for resultsEike Rathke
Problem was, that in array mode the result matrix of random values was created according to the dimensions of the formula cell range selected/resulting, which if transposed and displayed obeys the general rules of a repeating vector if not a 2D matrix. For example, entering the array formula =TRANSPOSE(IF({1,1,1};RAND())) (with , comma array column separator) is supposed to create a row vector of 3 columns transposed to a column vector of 3 rows. The selection created for the automatically determined result is 3 rows in one column, for which the RAND() was calculated, resulting in a column vector { 1 2 3 } which transposed gave a row vector { 1, 2, 3 } and displayed for one column such row vector is repeated as { { 1, 2, 3 } { 1, 2, 3 } { 1, 2, 3 } } of which the first column displayed is the repeating first value 1. With this change the dimensions of the JumpMatrix created by IF({1,1,1};...) is used to generate the RAND() matrix, resulting in a { 1, 2, 3 } row vector that then is transposed and displayed as expected. Change-Id: I267ff5d336a86372ee456fd929249e5f0444f843 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134247 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-05-12IsEmptyBlock() -> IsEmptyData()Luboš Luňák
It's unclear what "block" is supposed to mean, as that may mean "cells with no value", but a cell also may have a note, or since recently apparently also a sparkline. To make it even more confusing, there is IsBlockEmpty(), which may explicitly take bIgnoreNotes set to true, in which case it presumably should check only data, but then the recent sparklines addition still counts sparklines even in that case, which is presumably a mistake. Rename the data-only function to make it clear, and remove the extra argument from the empty-in-all-ways function. Change-Id: I8e3f75407d243b733d61640e2f54954762601ab1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134217 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-12fix up order of some ScDocument functionsLuboš Luňák
For better or worse the usual order of arguments in Calc is SCCOL, SCROW, SCTAB, so make this consistent. Change-Id: Ie63c75f5ae92f82cb757c0873f7ff569f331e0df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134229 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-12Simplify this a bitMike Kaganski
Additionally, use UNO_QUERY_THROW where the result is dereferenced unconditionally. Change-Id: Ia8860c037732e6f59d0a71e0ad7866121157f24a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134181 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-12Simplify ScTransferObj::SetDrawClipDoc a bitMike Kaganski
The two ScGlobal::xDrawClipDocShellRef.clear's were born in commit 623f5b26ffd77041d0b06d7ce9c3b32d05625440 Author Noel Grandin <noel@peralex.com> Date Tue Oct 27 15:12:58 2015 +0200 don't allocate rtl::Reference or SvRef on the heap from separate calls to 'delete ScGlobal::pDrawClipDocShellRef' and 'ScGlobal::pDrawClipDocShellRef = NULL'. Change-Id: Ie214feda4bc139bd6fccfbe525d7193a5cd02bce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134180 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-12tdf#148835 don't write any sparkline xml elements if none existsTomaž Vajngerl
Change-Id: Idd4058a88639cebceded13110dc367e74b6f7097 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134141 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-05-12Related: tdf#142635 Remove address parsing failback codeEike Rathke
This could not have been correct. It may have served some odd purpose back when it was added with commit 296baa2fb6dd4150a7855114093a9703cdc18b09 CommitDate: Tue Oct 5 18:14:37 2010 -0400 Ported calc-extref-interpreter-rework-*.diff from ooo-build. during the transition from ocExternalRef to ocPush with svExternal*Ref, but parsed syntactically wrong strings and all valid external document references with "'filename'#" had been detected earlier at the beginning or passed via pExtInfo->mbExternal. The case it treated here is neither a valid OOo nor ODF notation. Change-Id: I5a519aec4b251720da382cb76a93ab10c8aeb493 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134212 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-05-11Advanced Diagram support: UNDO/REDO support for Diagram DataModelArmin Le Grand (Allotropia)
Added support for UNDO/REDO for changes in Diagram ModelData. This is currenly applied/used in the DiagramDialog for it's Add/Remove actions (also supports Cancel of that dialog 1st time ever). But it is defined more general to add/support manipulating actions like clone/change_text etc. Also the UI/dialog at he end will not be/stay modal, so this is a test implemenation how to use it. It uses an extract/apply mechanism to get/set the Diagram ModelData at/for the UNDO action. That may be expanded as needed for additional data in he future. It may also be considered to modify the Connection/Point ModelData to shared_ptr internally completely to avoid copying these at all. OTOH it is not that much data to handle at all. Change-Id: I4702ed908b79a476177fe66c0e3284898c6adda5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134118 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-05-11search faster an array where most elements do not match (tdf#144777)Luboš Luňák
As said in previous commits, clearing and searching this array can be the major cost of large *IFS operations. And memchr() can do way better than what the compiler generates. Change-Id: Ibcaad05356f9fa33997593f929522b325c026579 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134139 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11reduce size of *IFS conditions array (tdf#144777)Luboš Luňák
The array is used to count the number of matching conditions e.g. in COUNTIFS, which can be only up to nQueryCount, which is sal_uInt8. So there's no need to count it as sal_uInt32, and doing so may cause 4MiB array per thread for full-column references, which causes easily causes 60% of time spent just clearing and checking the complete array. Change-Id: Id4bebf90619f7f2a721edb9cd31e6a11469579aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134138 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11no PerformQuery() with ScSortedRangeCache if not needed (tdf#144777)Luboš Luňák
It should not be necessary in that case, since the rows are restricted only to those that match, selected by BinarySearch(). Still at least assert that, just in case I'm missing something (or BinarySearch() doesn't quite match what validQuery() does). Change-Id: Ie91d3ba997692e5b3650b1549e8a38b6c5f44c01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134130 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11do not use ScSortedRangeCache inefficientlyLuboš Luňák
If the amount of data or size of the formula group is small, the caching is probably not worth it. And if rows are not absolute, then each formula cell would use a different range instead of reusing the cache. Change-Id: I42a82aaa5f4ffccc63e527793f46fc52fd539af6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134129 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11limit rows to ones having data when computing ScSortedRangeCacheLuboš Luňák
Change-Id: I2de9ea4887b6101f10eb3b8da6f3596de0ea09eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134128 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-11avoid somewhat expensive mdds position() call if possibleLuboš Luňák
Change-Id: I095f6285b9e1da5869ca08a0d8e6fae9ace40cfa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134126 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-11make BinarySearch() do proper SC_EQUAL with ScQueryEntry::ByStringLuboš Luňák
ScQueryEvaluator::isQueryByString() makes everything a string search in this case, so this one should too. Change-Id: Ic1ebd14515cfb7f253f022ca4f76699a6cb63468 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134137 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11use ScSortedRangeCache also for generic queriesLuboš Luňák
This enables use for e.g. VLOOKUP or COUNTIFS (as COUNTIFS does not use the specialized code for COUNTIF). Change-Id: Idad7503750d421f3f1c9ac34dfe95393fa3ead15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134124 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11make internal ScQueryCellIteratorBase functions protectedLuboš Luňák
Nothing is using these outside of the class. Change-Id: If2e1f2ce30980adeb1ce007f6084f492b314dd5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134122 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11keep only a reference to a vector if equal to what's wantedLuboš Luňák
This avoids copying the data repeatedly. Change-Id: Id3fadf8414c66143e12261a14b75b984415ed9a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134121 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>
2022-05-11make it obvious which column BinarySearch() operates onLuboš Luňák
It was setting the column to ScQueryParams.nCol1, which was somewhat confusing. Change-Id: I3ab2207f507a4dc3782ea78682dacb0b08c36b19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134123 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-11Drop IS_EDITMODE macro that is used only onceGabor Kelemen
Change-Id: I2fb5b8eb34aa18c35d3a53851ce8d92090d85590 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133982 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-05-11tdf#148430 Use atanh from <cmath> instead of our ownofftkp
Change wrapper in rtl::math::atanh to use atanh from <cmath>. Also changed all occurrences of rtl::math::atanh on files that use this function to directly use the standard atanh instead. Change-Id: Idc5c456f67291f5816756f023b61afde844b5ceb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133965 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-05-11Avoid useless default constructionMike Kaganski
Change-Id: I6b4cb48ab4e8f22b30a92fcf7d1de94b5cb9f34a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134068 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-11Resolves: tdf#132582 Display duration for calculated time values selectionEike Rathke
Change-Id: I634cd0fb059ed9c35849b435bcbd178cd84ac2ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134132 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2022-05-10tdf#108188, tdf#131190 - Verify that the page style is actually usedAndreas Heinisch
Change-Id: I007d26c6fcaf60d2a2378cc00e630da447f95a8a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134022 Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de> Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
2022-05-10sort out query iterator's BinarySearch() corner cases handlingLuboš Luňák
If the code detects the range is not actually properly sorted, set position to the first row and return false to force linear search. If the searched for value belongs before the first item, do the same, in which case the linear search should see that it is this case (before this case nRow was set to the first row regardless of where the searched for value belonged). Change-Id: I8ff346783d93d74ff409b19aea394e202885647d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134100 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-10make BinarySearch() work for SC_EQUAL, SC_LESS, SC_GREATERLuboš Luňák
Change-Id: I296686709688a9e3f2cda0864d73c79a17e33f49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134099 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-10make query iterator's BinarySearch() find the last matching itemLuboš Luňák
If the code found a matching value, it didn't bother finding the last one in the range if there were several adjacent ones. Change-Id: Ie1f4c7bd3dcbd2aaf653f5b74e159902de4cf93d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134098 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-10add tests of query iterator's BinarySearch()Luboš Luňák
The BinarySeach() function is rather strange/dumb. If it doesn't find the value, it tries to use the last previous value (i.e. it additionally does the fixing up that VLOOKUP, MATCH, etc.) do. At the some time, if there's a range of equal values, it doesn't find the last one (and so callers need to fix that up). Write some tests for that before I start touching the algorithm. Change-Id: Ife2388acad691cce7ffaf5490fa74b5a3d453926 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134097 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-14 23:50:29 +0000