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
Button response IDs are parsed late in the process of building a widget layout
from .ui files because they have their own section at the end. They show up
via QtBuilder::set_response() long after the button has been added to its
QDialogButtonBox. There appears to be no API to set a button's response after
it's already been added, so we need to re-add the button when we finally know
its response ID. The button box will then remove and re-add the button in
the right platform-specific order based on the response ID.
Pull out the button box adding logic to a separate function so we can do
the same thing from the two places it's required.
Change-Id: I29527eabcf68105b5e8c6fbffd4ca3822b7a5acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206476
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@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>
The default drawing style names a theme color now, and a PPTX saved
to ODF and back came out with every shape green. A shape that really
did name a theme color lost the reference and came back plain.
A color item holds the color and the theme reference together.
Setting a plain color started from the item the shape inherits from
its style and overwrote the color alone, so the inherited reference
won. Clear the reference, which is what an explicit color means.
The ODF export repeats each shape's fill on a paragraph style,
applied after the graphic style, and the paragraph properties had no
complex color. Carry it there too.
A style's graphic properties took a complex color only when it was
the character one, matched by element name. Match on the context id,
which the fill and stroke colors share.
Add a round trip test through ODF and PPTX with a plain shape, a
themed one, and a themed one with a luminance modulation.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia9550222d18a243287240e4184666d78d0abdd22
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10060
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 07cf37b104983f765d3e1005f677e0058df12026)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210510
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
reproduce by loading ooo59043-1.odt and exporting it to the binary doc
format, which toggles the tracked-change display.
that save-time show and hide joins and splits the text nodes, and can
leave the spell wrong list with an invalid end past the now shorter
text.
the idle autospell then maps that end and asserts, here with nIndex 15
on a 12 char node:
soffice.bin: sw/source/core/text/txtfrm.cxx:1344:
Assertion `nIndex <= pNode->Len()' failed.
#4 sw::MapModelToView (nIndex=15) at txtfrm.cxx:1344
#5 SwTextFrame::MapModelToView (nIndex=15) at txtfrm.cxx:1385
#6 lcl_CalculateRepaintRect (nChgStart=0, nChgEnd=15) at txtedt.cxx
#7 SwTextFrame::AutoSpell_ at txtedt.cxx:1519
#8 SwLayIdle::DoIdleJob_ (ONLINE_SPELLING) at layact.cxx:2171
#9 SwLayIdle::DoIdleJob at layact.cxx:2312
#10 SwLayIdle::SwLayIdle at layact.cxx:2573
#11 SwViewShell::LayoutIdle at viewsh.cxx:927
#12 sw::DocumentTimerManager::DoIdleJobs at DocumentTimerManager.cxx:179
AutoSpell_ already tolerates the over-long end, set with std::max
against the text length a few lines up, and the word scanner stops at
the real end.
so clamp the repaint range the same way before it is mapped.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I5ad086753f8b3fc0f838a45a7291cd62a4d4a343
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6699
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 1920f81f2df779c9787256c9ad93903640817419)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210508
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
By now, almost all a11y implementations implement both,
the XAccessible and XAccessibleContext interfaces themselves,
and they do so via the OAccessible base class.
One remaining case that only implements the XAccessible interface
directly is UnoControl. XAccessible::getAccessibleContext
is used from within AccessibleControlShape::Init to get the
accessible context. That accessible context however
is an OAccessible and implements both, the XAccessible
and XAccessibleContext interfaces again.
Stop requiring that UnoControl implements XAccessible
by instead adding a dedicated new method UnoControl::getAccessible
to directly get the OAccessible without relying on
the XAccessible interface being implemented by UnoControl.
In AccessibleControlShape::Init, cast to UnoControl
instead of querying for the XAccessible interface
and call the new method directly.
Stop implementing the XAccessible interface in
UnoControl as it is no longer needed now.
This aligns the UnoControl a11y logic more with how
a11y is implemented elsewhere across the code base.
Sample steps to trigger the modified code
when using the gtk3 vcl plugin on Linux:
* start the Orca screen reader
* start Writer
* insert a few push button controls using
"Form" -> "Push Button" and then clicking into
the document and dragging to insert
* disable design mode using "Form" -> "Design Mode"
* focus one of the controls by clicking on it
* press the Tab key to move focus between the controls
No differences in behavior were observed when
doing this with or without this change in place.
Side note: Announcement of the controls when they
receive focus didn't work (reliably) when opening an
existing document containing form controls instead of
inserting them into a new one, but that is preexisting
and unrelated to this commit.
Also adjust test AccessibleFixedTextTest::testFixedText
of the CppunitTest_toolkit_a11y test suite
accordingly that was assuming that it can
query the XAccessible interface directly
from the UNO control.
Change-Id: I8cc3902a8de725eda3d810920f1da2d390c06f73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210464
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The UndoManager Java UNO test is currently making use of the
XAccessibleAction interface in order to press a button programatically.
In order to retrieve the accessible, it was querying the
UnoControl (via its UNO interfaces) for the XAccessible
interface, then getting the associated XAccessibleContext.
This relies on the implementation detail that UnoControl
implements the XAccessible interface, which will no longer
be the case after upcoming commit
Change-Id: I8cc3902a8de725eda3d810920f1da2d390c06f73
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Sep 3 15:55:32 2026 +0200
a11y: Get UnoControl accessible without implementing XAccessible
Therefore, stop relying on this implementation detail.
Ideally, accessibility implementation details shouldn't be used
at all. But for now, in a first step and in order to not have to rework
more logic now, switch to retrieving the XAccessible for/from the window
peer instead, using the mechanism introduced in
commit d1a25112bb
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 18 17:49:48 2025 +0200
java a11y tests: Don't rely on XWindow being XAccessible
Change-Id: I4817bd7efa8a6ed57a514b3e4fecf3d6545fbc13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210487
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
ODF has no name for this chart type, so the file says two things at once, the
way a histogram already does: chart:class names the scatter chart, which is the
nearest a reader that knows nothing of correlation circles can make of it, and
coext:class beside it names the type itself. A reader that knows the coext name
gets the chart back as it was saved.
The series need no new shape in the file. The feature column is the range of
the series and the two dimension columns are a domain each, which is where a
bubble chart already keeps its x and y values, so both the reading and the
writing of them follows the bubble path rather than a new logic.
The schema the tests validate against lists the values coext:class may take, so
the new one is added there beside the histogram.
The test document is one block of five columns: three features and then the two
dimensions, the shape the wizard asks for. The test checks after a round trip
that the chart type came back, that the file carries both class names, and that
every series still holds its feature column beside the two dimension columns.
Change-Id: Iac73ff357c7490b4f38a4390c63948cf148d8585
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8106
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 4e59ea1c83e61b8dc2647f9a915884f9d461165d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210498
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
If the parent widget already has a layout, then creating a new
widget and passing the parent in the widget's constructor will
add the widget to the layout. If the widget is later added
to the layout again, it will be removed from the layout and
re-added. This is unecessary.
Change-Id: I64e27080a1546e126dfc8ee57d3e1e558574d6a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206477
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
...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>
This means that native Qt widgets are used for this dialog
now when using the qt5 or qt6 VCL plugin and starting LO with
environment variable SAL_VCL_QT_USE_WELDED_WIDGETS=1 set.
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: If442498741a2f22a8960bdd7acb7314e329f3f8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210486
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
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>
Xisco Fauli