see on loading forums/xlsx/forum-mso-en4-748529.xlsx and doing a
hard recalculation, which aborts with:
soffice.bin: sc/inc/formulacell.hxx:514: void ScFormulaCell::MaybeInterpret():
Assertion `!rDocument.IsThreadedGroupCalcInProgress()' failed.
#4 ScFormulaCell::MaybeInterpret at sc/inc/formulacell.hxx:514
#5 ScFormulaCell::IsEmpty at sc/source/core/data/formulacell.cxx:3153
#6 FillMatrixHandler::operator() at sc/source/core/data/column2.cxx:2636
#7 sc::ParseBlock at sc/inc/mtvfunctions.hxx:66
#8 ScColumn::FillMatrix at sc/source/core/data/column2.cxx:2708
#9 ScTable::FillMatrix at sc/source/core/data/table1.cxx:2700
#10 ScDocument::FillMatrix at sc/source/core/data/documen8.cxx:400
#11 ScInterpreter::CreateMatrixFromDoubleRef at sc/source/core/tool/interpr5.cxx:386
#12 ScInterpreter::ScSpilledRange at sc/source/core/tool/interpr1.cxx:1703
#13 ScInterpreter::DispatchOpCode at sc/source/core/tool/interpr4.cxx:3868
#14 ScInterpreter::Interpret at sc/source/core/tool/interpr4.cxx:4414
#15 ScFormulaCell::InterpretTail at sc/source/core/data/formulacell.cxx:2209
#16 ScColumn::CalculateInThread at sc/source/core/data/column2.cxx:3270
#17 ScTable::CalculateInColumnInThread at sc/source/core/data/table1.cxx:2740
#18 ScDocument::CalculateInColumnInThread at sc/source/core/data/documen8.cxx:421
#19 Executor::doWork at sc/source/core/data/formulacell.cxx:5463
ScSpilledRange calculates cells itself. It calls MaybeInterpret on the
master cell of the dynamic array, and CreateMatrixFromDoubleRef then
covers the whole spill range, so FillMatrix asks every cell in that
range whether it is empty and IsEmpty calculates it. A worker thread
inside a threaded group calculation must not calculate a cell.
The dependency evaluator can't cover it either, only the operand's own
cell is named by a reference token and how far the spill reaches is
known only once that cell has been calculated
an issue since:
commit 9b97b0fc91bce4b8726ea210347e8ea84270e148
Date: Mon Jul 6 13:09:39 2026 +0000
sc: add the # postfix operator for spilled-range references
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Id58e88d1bd927576e4723dd23bc119673feed108
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11285
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 89af05e8a5e8ce4ae337e2f0048f670940573930)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210542
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
As Eike indicated in https://bugs.documentfoundation.org/show_bug.cgi?id=146404#c4
COLOR format codes are preserved in ods/fods format.
The pb was the missing map back.
Indeed, we had the mapping for [COLOR<something>] => Color value (eg: "ffaa16")
but not the reverse mapping Color value => [COLOR<something>]
Eike had provided the right code pointer in xmlnumfi.cxx.
First, I thought using PaletteManager but this one is in svx and svx shouldn't be used in xmloff
(dependency pb).
Then I used ChatGpt (GPT-5.6 Luna) and it pointed the right process.
It just consisted to use a similar callback system (DECL_LINK, IMPL_LINK, LINK) of GetUserDefinedColor.
In addition, by testing all this, I noticed that maList in XColorList::GetIndexOfColor was empty.
So I added the Load call in case mbListDirty is true.
Change-Id: I0ef6b5901f2e4c757e88994412dbf79a13100ffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210518
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
The pb appears with 0d7be893f5:
Table Style: introduce insert/delete Table... command available from
with ods pData->GetTableStyleInfo() is nullptr so buttons like "Modify"
but also "Delete" or all the "Options" part, are enabled (sensitive=true)
with xlsx pData->GetTableStyleInfo() is not null and these same buttons are disabled.
I don't know if the return of GetTableStyleInfo is ok for both cases but I don't know why
we should test this to know if these buttons should be enabled or not.
To be homogeneous, I also did the same for m_xAssignFrame.
Change-Id: Ib2295f26b53163a9612159c1564227d9b2b8ca9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210506
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
...at
> engine/sc/source/ui/unoobj/chart2uno.cxx:1622:20: runtime error: downcast of address 0x7c6579dde660 which does not point to an object of type 'ScDoubleRefToken'
> 0x7c6579dde660: note: object is of type 'ScExternalDoubleRefToken'
> 00 00 00 00 b0 11 4e 1b f5 7b 00 00 00 00 13 00 01 00 00 00 00 00 be be be be be be 80 16 8d 79
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'ScExternalDoubleRefToken'
> #0 in (anonymous namespace)::InsertTabNumber::operator()(boost::intrusive_ptr<formula::FormulaToken> const&) const at engine/sc/source/ui/unoobj/chart2uno.cxx:1622:20
> #1 in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag> std::__for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, (anonymous namespace)::InsertTabNumber>(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, (anonymous namespace)::InsertTabNumber&) at ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/17.0.0/../../../../include/c++/17.0.0/bits/stl_algo.h:159:6
> #2 in (anonymous namespace)::InsertTabNumber std::for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, (anonymous namespace)::InsertTabNumber>(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<boost::intrusive_ptr<formula::FormulaToken>*, std::__cxx1998::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>>, std::__debug::vector<boost::intrusive_ptr<formula::FormulaToken>, std::allocator<boost::intrusive_ptr<formula::FormulaToken>>>, std::random_access_iterator_tag>, (anonymous namespace)::InsertTabNumber) at ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/17.0.0/../../../../include/c++/17.0.0/bits/stl_algo.h:3846:7
> #3 in ScChart2DataProvider::detectArguments(com::sun::star::uno::Reference<com::sun::star::chart2::data::XDataSource> const&) at engine/sc/source/ui/unoobj/chart2uno.cxx:1961:16
> #4 in non-virtual thunk to ScChart2DataProvider::detectArguments(com::sun::star::uno::Reference<com::sun::star::chart2::data::XDataSource> const&) at engine/sc/source/ui/unoobj/chart2uno.cxx
> #5 in oox::drawingml::ChartExport::getSplitCategoriesList(rtl::OUString const&) at engine/oox/source/export/chartexport.cxx:723:106
> #6 in oox::drawingml::ChartExport::exportSeriesCategory(com::sun::star::uno::Reference<com::sun::star::chart2::data::XDataSequence> const&, int) at engine/oox/source/export/chartexport.cxx:4498:89
> #7 in oox::drawingml::ChartExport::exportSeries_chart(com::sun::star::uno::Reference<com::sun::star::chart2::XChartType> const&, cpo::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::chart2::XDataSeries>> const&, bool&) at engine/oox/source/export/chartexport.cxx:4048:21
> #8 in oox::drawingml::ChartExport::exportAllSeries(com::sun::star::uno::Reference<com::sun::star::chart2::XChartType> const&, bool&) at engine/oox/source/export/chartexport.cxx:3881:5
> #9 in oox::drawingml::ChartExport::exportPieChart(com::sun::star::uno::Reference<com::sun::star::chart2::XChartType> const&) at engine/oox/source/export/chartexport.cxx:3687:5
> #10 in oox::drawingml::ChartExport::exportPlotArea(com::sun::star::uno::Reference<com::sun::star::chart::XChartDocument> const&, bool) at engine/oox/source/export/chartexport.cxx:2932:33
> #11 in oox::drawingml::ChartExport::exportChart(com::sun::star::uno::Reference<com::sun::star::chart::XChartDocument> const&, bool) at engine/oox/source/export/chartexport.cxx:2302:5
> #12 in oox::drawingml::ChartExport::exportChartSpace(com::sun::star::uno::Reference<com::sun::star::chart::XChartDocument> const&, bool, bool) at engine/oox/source/export/chartexport.cxx:1570:5
> #13 in oox::drawingml::ChartExport::ExportContent_(bool) at engine/oox/source/export/chartexport.cxx:1480:9
> #14 in oox::drawingml::ChartExport::ExportContent() at engine/oox/source/export/chartexport.cxx:1457:5
> #15 in oox::drawingml::ChartExport::WriteChartObj(com::sun::star::uno::Reference<com::sun::star::drawing::XShape> const&, int, int) at engine/oox/source/export/chartexport.cxx:1273:5
> #16 in XclExpChartObj::SaveXml(XclExpXmlStream&) at engine/sc/source/filter/excel/xeescher.cxx:1897:22
> #17 in (anonymous namespace)::SaveDrawingMLObjects(XclExpObjList&, XclExpXmlStream&) at engine/sc/source/filter/xcl97/xcl97rec.cxx:304:16
> #18 in XclExpObjList::SaveXml(XclExpXmlStream&) at engine/sc/source/filter/xcl97/xcl97rec.cxx:414:5
> #19 in XclExpRecordList<XclExpRecordBase>::SaveXml(XclExpXmlStream&) at engine/sc/source/filter/inc/xerecord.hxx:386:21
> #20 in ExcTable::WriteXml(XclExpXmlStream&) at engine/sc/source/filter/excel/excdoc.cxx:717:14
> #21 in ExcDocument::WriteXml(XclExpXmlStream&) at engine/sc/source/filter/excel/excdoc.cxx:918:44
> #22 in XclExpXmlStream::exportDocument() at engine/sc/source/filter/excel/xestream.cxx:1163:18
> #23 in oox::core::FilterBase::filter(cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/oox/source/core/filterbase.cxx:500:83
> #24 in oox::xls::ExcelFilter::filter(cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sc/source/filter/oox/excelfilter.cxx:200:27
> #25 in SfxObjectShell::ExportTo(SfxMedium&) at engine/sfx2/source/doc/objstor.cxx:2743:25
> #26 in SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) at engine/sfx2/source/doc/objstor.cxx:1853:19
> #27 in SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString const&, rtl::OUString const&, SfxItemSet const&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sfx2/source/doc/objstor.cxx:3263:39
> #28 in SfxObjectShell::CommonSaveAs_Impl(INetURLObject const&, rtl::OUString const&, SfxItemSet&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sfx2/source/doc/objstor.cxx:3051:20
> #29 in SfxObjectShell::APISaveAs_Impl(std::basic_string_view<char16_t, std::char_traits<char16_t>>, SfxItemSet&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sfx2/source/doc/objserv.cxx:329:19
> #30 in SfxBaseModel::impl_store(rtl::OUString const&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&, bool) at engine/sfx2/source/doc/sfxbasemodel.cxx:3247:42
> #31 in SfxBaseModel::storeToURL(rtl::OUString const&, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at engine/sfx2/source/doc/sfxbasemodel.cxx:1830:13
> #32 in UnoApiTest::save(TestFilter, cpo::uno::Sequence<com::sun::star::beans::PropertyValue> const&, char const*) at engine/test/source/unoapi_test.cxx:386:16
> #33 in testCool14390_ChartExternalRef::TestBody() at engine/sc/qa/unit/subsequent_export_test4.cxx:881:5
apparently caused by 003c0007c13e443fe4e520d1b70586266abf7811 "reduce
Sc*Ref*Token virtual calls". Now using the helper that was introduced there.
Signed-off-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Change-Id: I3e1c82e8069cb03af29e8dc260017fc3e867f72b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11014
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 3797f2792490a1c114ce0a80db2d544bce08670b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210500
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
commit c54f872f50
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Apr 9 09:00:54 2026 +0200
sc: Use activated row param in ScPivotLayoutTreeListData::DoubleClickHdl
had switched from passing an int by value to
passing a weld::Entry by ref to the lambda
function in ScPivotLayoutTreeListData::DoubleClickHdl.
Since that function is run asynchronously, this can
result in the weld::TreeIter passed to
ScPivotLayoutTreeListData::DoubleClickHdl
already having been deleted by the time it's
accessed in that lambda function.
Create a copy of the iterator held by a std::shared_ptr
and pass that one by value to avoid/fix the issue.
Change-Id: I2387aca5eb5d572d0e6a551589c07a6c683185f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210483
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This fixes a 24.2 regression from Khalid's commit 4b743de97f.
The problem I'm trying to fix is that setting optimal column width
is not necessarily providing enough width to avoid seeing '###'.
The reason is that GetOptimalColumnWidth calls GetTextWidth
with MapMode disabled, so no subpixel calculations were done.
However LayoutString does have MapMode enabled,
so it calculates a different length than what optimal column got.
Surely that must always be wrong. But Khalid's similarly more-correct
commit triggered a lot of 'regressions'. However, this should be
moving in the right direction as tdf#168002 suggests
that mbSubpixelPosition should always be true in the future.
Since it is needed for width, it seems reasonable that it should
also be done for height...
Change-Id: I30590ebba8b3027c5214ee075a1a258d3a61b8c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210438
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
* Recognize LAMBDA during dynamic array analysis; LAMBDA
never produces an array, but it can be part of a formula
that generates one.
* Fix handling of LET; subexpressions before the last should
not affect the result, unless we are willing to to a more
thorough analysis.
* Update test to check for the new behavior.
* Account for svExternalDoubleRef.
Change-Id: Ia9a4761079de986906ac70252066d8d9b4655f59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210461
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A table's totals row exported even when the table had no header, or
when its only content was a plain number wrongly declared as a text
label. Excel rejected both cases and repaired the file on open.
Only export a totals row when the table has a header and a column
actually shows a real label or total. Otherwise leave the row as
plain data, matching what Excel itself does when it repairs such a
file.
Signed-off-by: Samuel Mehrbrodt <samuel.mehrbrodt@collabora.com>
Change-Id: I6dc84680780805d8cfe666d681a62a9a907605d2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10367
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit cfb01061aec26a218dcd1e4b5cccad395d2a5489)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210453
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Using the rounded integer width of a single character
and using that to determine how many times to repeat it in a give space
is bound to result in disaster.
Instead, determine an approximation of the real size of the string.
This is just layout stuff - no idea how to capture it in a unit test.
Change-Id: Ie0cbc891d986357a1037b1476cb1cd4c9601e876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210439
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
The XLSX export wrote the label as a bare <font> element, so a checkbox
came back with the control default font at 10pt and adjacent labels
overlapped. The label's font name, size and colour, its bold, italic,
underline and strikeout, and its horizontal and vertical alignment are
now written out.
The underline stopped reaching the export altogether when the control
property list started asking for "FontLineStyle", which no control model
has: commit 3187193a61 (tools: rename
FontUnderline to FontLineStyle, 2016-01-29) renamed the VCL enum and
took the UNO property name string along. The same rename hit
sw/source/filter/html/htmlforw.cxx, which is not handled here and needs
a separate fix. A double underline also needs the "fontN" class on the
underline element, which the import compared with a literal "font4",
introduced with no explanation given in commit
04c272eb83 (dr77: #i114128# import legacy
drawing controls, 2010-08-26). N is the index into the workbook font
table, and is treated as one now.
Excel keeps the label font in the VML shape, in the DrawingML run
properties and in a workbook font record, and builds its model from the
DrawingML, while we read the VML and the record it names. Both are
written here so that the two applications show the same document. TODO:
read the label font from the DrawingML run properties, as Excel does.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I87259d25a68829f6c1a78179f8e3aa7811a5688f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9927
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit ca86699205743f2709f3cd5d412a8a3f0d3fba38)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210334
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
OOXML leaves the @ of =@$I$112# out of the saved text and expresses it
by keeping the cell a plain non-array formula, while an @ over
anything wider keeps its _xlfn.SINGLE. The import didn't put it back,
so the cell showed the row-aligned value while its formula read
=$I$112#, the spelling for a spill.
The @ goes back the way the binary format import already does, and
only for that thinned shape: a non-master cell whose whole formula is
one reference with the operator after it, not even parentheses.
Anywhere wider, injecting an @ would force the operand into an array
and change the result, so (A1)# is left alone.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ib8071804eaa805880e20552eeee92665756c5cd7
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10164
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 273dbf42009efe6d9f59edf28a4272cfe366196f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210314
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The compiler decides whether a blank is the intersection operator by
looking at the tokens on either side. Both parenthesis tokens have the
separator type, which those checks read as "not a reference", so
=SUM((A1:B1,A2:B2) A1:A2) didn't parse even though it should intersect
the list with the range. The parentheses are now accepted by their
opcode, and so is a reference list built from a converted separator on
either side.
The blank also keeps the parenthesis after it a group. An operand
followed by a parenthesis normally opens an argument list for a
callable, but with the intersection blank in between there is no call,
so ocCall is not injected. A name in front still calls either way.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I8e4b5fb7136419b4e937c8abb521711a8d418af8
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10162
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit b12a7af0e1aab942aa5014b799a96271d03c472f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210305
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A symbol like F25:IF lexes as a single range reference because IF is
also a valid column name, and then it doesn't name a valid range. The
whole symbol was kept as an unknown name, so =SUM(F25:IF(TRUE,F26))
gave #NAME? instead of summing up to the cell the call returns.
When such a symbol is followed by an opening parenthesis the lexer now
backs up to the range operator and reads it again (a symbol that isn't
a reference at all is already handled elsewhere). The reference then
stands on its own and the call after the operator is read separately.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I709de89206008894b1a07b482ac1ca5457ab059d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10161
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit cc8e9277c510bb8f95d11a37e326a68bd8bca513)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210304
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A reference list is built from the separator between two parts of a
parenthesised expression, and which parts join was decided from the
opcodes at the top of their compiled code. That was wrong both ways:
INDEX returns a reference but wasn't counted, so (INDEX(A1:A3,1),B1)
fell apart, while (F25, F26%) didn't parse at all even though it
should give #VALUE!.
The left part now has to end in a reference or an opcode that returns
one, INDEX among them. The right part joins if it starts with one, or
with a nested list, IF, CHOOSE, a lookup, the @ operator or an error
constant. What it then makes of that reference is the calculation's
business.
A part starting with anything else leaves the separator a separator
and the formula doesn't parse, which is what the producing
application refuses at its formula bar too.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: If65d2f0f9cc599729564cfc5369c0479b07c93e8
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10160
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 50ddf65b640a9cb88aea56be4367a3e44152c230)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210303
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A reference list holds several ranges, so there is no single value an
operator could work on. GetDouble and GetString had no case for it and
fell through to their parameter error, so =(A1,B1)% and =(A1,B1)&"x"
came out as Err:504 instead of #VALUE!. They report #VALUE! now. A
function that takes the list itself, like SUM, still reads it whole.
The union operator gave the generic Err:502 when one of its parts was
a value instead of a reference, as in =(A1~5). That reports #VALUE!
now too.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I8da8a30a691f2b939d04af7f1abd58e586cd5b7f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10159
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 2cd6e380f8aec3b691dc15ade6798191b8d64d89)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210302
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A # spilled range travels as a matrix that carries the range it was
read from, so a plain cell can reduce it to the value of the row it
lines up with. Every operator dropped that range on the way through
GetMatrix and PushMatrix, so =A1#% on a master spilling 1, 2 and 3
came out as 0.01 instead of the row-aligned 0.02.
The range is now noted when a matrix operand that carries one is
popped, and put back on a result of the same shape - those are the
only way in and out. The note only lasts for one token, and two
operands with different ranges cancel it. Functions don't get it,
because something like SORT is free to move the values around.
The values of such a result are the operator's own, not the cells'.
So ScMatrixRangeToken now answers the two questions separately: the
range says where the values sit, and a second flag says whether the
values are still the ones the cells hold.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ie4851dcc208f20220f07cd75a691aee88cfdc5ac
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10158
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit a393976584be143df7cb40623f31322e46889756)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210301
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The # operator refers to the master cell before it. ScSpilledRange
took its operand with PopSingleRef, which turns anything that isn't a
single reference into a parameter error, so a # after a range or a
reference list came out as Err:504 instead of #REF!. Anything covering
more than one cell has no master, so it now reports #REF! too, same as
an empty cell or a non-master already did.
An array formula has to give the same single #REF!. The operand's
parameter class wasn't declared, so in an array context the range
operand got turned into a matrix and the operator ran once per cell -
a dynamic-array master then spilled the error matrix or gave #SPILL!.
Declaring the operand as a reference makes the operator take the range
as a whole.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I196f67b644035fbbf87b08c605a5dd2719831ba0
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10157
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 54382bfb0bf025ee4839a6f6d86a07123e893400)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210294
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The # postfix operator was parsed at the same level as the percent
sign, which is looser than the prefix operators. Because of this
=@A1# compiled to the spill range of an implicit intersection and
=-A1# to the spill range of a negated value. Neither of those means
anything, and OOXML writes the # around the reference alone in both
cases.
The # is now parsed right after the factor it follows, tighter than any
operator that can come before it. A whole range reference goes inside,
because the lexer reads A1:A3 as a single reference. The percent sign
stays above the reference operators, so =A1%# leaves the # with nothing
to bind to and doesn't parse, and the export drops such a # (OOXML has
no spelling for it either).
A blank between two operands is only the intersection operator if both
sides yield a reference. The # does, so the checks that keep the blank
alive and that keep the operator once the operands are known had to be
told about it.
The interpreter passes the spill range on as a matrix that carries the
range it was read from. The intersection, range and union operators
only took references and refused that, so PopReferenceOperand now
hands them the carried range as a double reference.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I1a587bf291ff639b326a366b8efc332106eb5fd3
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10156
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit c589c34aaec00d60fc47f1933762b105f9d22de3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210293
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
OOXML writes @ and # as calls and a reference union as a parenthesised
list, so for each of them we need to know how far the sub-expression
under it reaches. CreateStringFromTokenArray worked that out from the
text it had already written. The problem with this is that every pair
it spliced in shifted all the offsets that were still waiting behind
it, so it kept breaking.
Instead of patching the text, OOXMLRewriter builds a second
token array in the shape OOXML spells out and the writer walks that as
it stands. The call names and the parentheses are ordinary tokens, so
there is nothing to splice and no offsets to keep track of. It is the
same trick RewriteMissing already plays a few lines further up, and it
means the input and the output can be looked at side by side.
The # changes place, from behind its operand to a call in front of it,
so it gets an opcode of its own. _xlfn.ANCHORARRAY spells ocAnchorArray
now, and ocSpill keeps the native postfix spelling with no OOXML one at
all, so the postfix form cannot end up in a file by accident. The
import already rewrote the call back into the postfix operator and now
recognises it by opcode instead of by position. The @ stays
ocSingleValue, it is already in front of its operand so only the
parentheses are new.
The OFFSET() literal argument is swapped for the reference error in
the same pass, instead of the writing loop jumping over tokens.
A unit test drives the rewrite on its own: token array in, token array
out, one case per shape. The shapes that end up with nothing to wrap
are in there too - a lone @, one with a missing argument, and text that
never parsed - since those are the ones where dropping a token is the
only change.
Also drop the dead "@" and "#" rows from the OOXML symbol table, the
rows above them already have _xlfn.SINGLE and _xlfn.ANCHORARRAY.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I63944fb85b5c4388f304f7d94afd0b4f347d7782
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10155
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 4feac84950f5b524d99e277481de50f7b45a8d2f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210292
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Before, it generally wasn't saving ANYTHING
because rMark is normally not marked,
and even if it is, it could be random.
The only time rMark means anything is if rSearchItem.GetSelection().
But even that doesn't help because the undo has no idea of range.
ScUndoReplace::Undo attempts to undo the entire document,
so definitely more than bOnlyMarked needs to be included.
In fact, even sheets that don't even have a match
need to be backed up. Entirely.
This seriously needs to be looked at by a Calc Pro
who could optimize this by passing rMatchedRanges
to ScUndoReplace. And only CopyToDocument a RangeList.
But of course, there is also bMatchedRangesWereClamped...
which thankfully doesn't affect styles, only text.
Change-Id: I2087e255e3e4b3387b388e1f2d28c19717e50342
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210247
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Michael Weghorn