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>
Qt plugin automatically orders buttons for each platform based on
the button's role, which we derive from the Gtk .ui file's
action-widget response code. But to do that conversion from response
code to Qt button role, we need a standard response.
Without a standard response, the button has no role, and gets ordered
to the right of OK/Cancel buttons on Mac. With the correct role, it
is correctly placed far-left along with the Help button.
Change-Id: I16d3126d4999649e7aa6e72ec5e7b1a25f48c2a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210223
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
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>
as part of the process of merging the Outliner code into the normal EditEngine paths.
So instead of keeping a bunch of information "on the side" and then having to merge information
from multiple sources, it all lives where it logically belongs.
Also take the chance to rename the depth/getdepth/setdepth
fields and methods to NumberingDepth, which makes the purpose
more obvious.
Change-Id: I314673ee1b9efa14f178ac34a122995a554cd788
Signed-off-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10551
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 284bbe0af12b96844976f30bb35ade3a327ea76d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210503
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
...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>
The dialog can e.g. be triggered following the steps
described in tdf#173243:
* open attachment 208203 from tdf#173243
* use "Data" -> "Pivot Table" -> "Insert or Edit..."
and confirm "Current Selection" to trigger the
"Pivot Table Layout" dialog
* drag "Date" to row fields, "Value" to data fields.
* drag another "Value" to data fields and double-click it
Change-Id: Id13a2cbca2d407e40bf0885ee82650aa0a366e17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210485
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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>
A correlation circle plot reads the ends of its range differently from every
other chart type: the last two columns are the dimensions its points are placed
against and the columns before them are the features. One range holds the lot,
so nothing about the entry gives that away, and a reader who does not already
know it has no way to work it out.
Display a information label under the range input saying the last two
columns of it are component dimensions and the columns before that are
features.
Change-Id: Ib7d27aad189f12be188f61b1fc317dd1e718b803
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8105
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 2cbf62e18df956ed23c77932cd5e38424e7baa1f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210470
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The entry sits next to the bubble chart, under the same switch that keeps the
chart types wanting free x values out of the list where they do not belong. It
has one sub type, no three dimensional look and no stacking.
The two images are placeholders: a circle with a cross and a few arrows
out of the middle. They need a designer's hand before this ships.
A test drives the wizard the way a user would: it picks the type, types one
range whose last two columns hold the dimensions, and checks that every column
before them became a series holding that column beside the two dimension
columns. A second test reopens the ranges of that chart and checks the range
comes back as it was given.
Change-Id: If8b5275244a2456a22235a6ce2d3d51fcff6cb94
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8104
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 7a7fc603047e065ebbc20f8bc5dc814d6079e082)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210469
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
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
Rename testTdf112501 to
testTdf112501PivotCompactModePopupButtonPlacement. The old test name was
based on the original bug number. Rename it to reflect the actual tested
behavior
No functional change.
Change-Id: If8f032bedbababc7fc5f08896a720c16018be9c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210388
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
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>
UnionSpillIntersectionOperatorTest.xlsx was written by the producing
application, so the results stored in it are the ones that application
computes. Each row compares one with ours, the sheet's master cell says
whether every row agrees, and rows refused at the formula bar keep the
refused formula as text. It covers the @, # and % operators next to the
range, union and intersection operators, alone and combined.
The rows are checked against the stored results, then again after a
recalculation and after an xlsx save and reload, so both the values the
file came with and a fresh evaluation of our own are covered.
The whole verdict column is reported in one go, naming for each failing
row the two values compared and the tested cell's value and formula.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I26a970d82ba5c96737455d75e85b90aec3d22004
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10165
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit f45435e3cf797d08dc13f85c4b2a6cad0dd8d77a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210315
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
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 formula writer substitutes an error constant for anything that has
no spelling in the target format, and it took that string from the
native symbol table. That table is translated, so a build in another
language wrote a translated "#REF!" into the saved formula, where only
the English spelling reads back. It now takes the string from the
table of the grammar being written, which changes nothing for the
native grammar.
Reading had a gap of its own. The OOXML table had a second "#REF!" row
for the stop opcode, and the symbol map keeps the first spelling it
finds in opcode order, so that row shadowed the error constant and a
bare #REF! read from a file gave #NAME?. Nothing needs a spelling for
the stop opcode, so the row is gone.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Idbe8ce87d6ad6346106622379ff59908a36eb7f7
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10163
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 75160522f6a9de4999b824725326475ba8d713f1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210313
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
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>
Michael Weghorn