- a form with a header row and a hundred empty bordered rows below it
printed only the header row. Calc drops a run of 84 or more equally
formatted rows below the last cell with content, and everything under
it, so the print range ended at the last row with data. The borders
were on screen all along, so only printing, the print preview and the
PDF export showed it.
- the run is measured from the last row with data, so typing changed
the result. On a form whose borders end at row 100, text in row 16 left
84 rows below it and the borders stayed away, text in row 17 left 83
and the whole form printed.
- ScDocument::IsPrintEmpty prints a page that carries a border and no
content, and suppresses one carrying only a colour. A bordered run is
therefore kept now, unless it is wider than SC_VISATTR_BORDER_STOP in
its own length or in its distance below the data, which is the whole
column case i30830 is about. The length stays the same as the sheet is
filled in, the distance stops a chain of shorter bordered ranges
reaching the sheet end. Neither measure applies to a run under
SC_VISATTR_STOP rows, because a run that short was never dropped.
- the print range also sets where Ctrl+End lands, how far the desktop
scrolls and what range is written out on save, so all three grow with
it. In the browser the scroll extent comes from the cell area, so it
stays where it was.
- a run has to meet one more condition than before to be dropped, so no
document prints less than it did, and the ones hitting this bug print
more.
- the tests say a bordered form is printed, a colour under the content
does not pull the print area down, a border too wide or too far down
does not either, a frame round a whole column leaves the printout
ending at the last row with content, and a form is printed wherever the
content ends, including when a font change splits it in two.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I44d041cdbbcde7bfa69b53035f5bebc8d59f9bdd
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/14112
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 00e5de0a8bd89e5f5c9f7b19fef85331354c4458)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211943
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Using &* can be problematic if the pointer is null. In this case I don’t
think it matters, but using unique_ptr::get() is probably easier to
understand anyway. This also paves the way for a later compiler plugin
to check for this.
Change-Id: I6b399d57cdf580d40721789bf3d6e7607c56fd6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211751
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Using &* can be problematic if the pointer is null. In this case I
don’t think it matters, but using unique_ptr::get() is probably
easier to understand anyway. This also paves the way for a later
compiler plugin to check for this.
Change-Id: I064def383ccf4b1ff263a70cd0c7775ff6fbbc8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211750
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Copying a sheet to a position at or before its source left the
relative sheet references in the copy pointing at the wrong
sheets, one or two places too far to the right. CopyTab moves the
source index by one when the new sheet is inserted before it, and
AdjustRelativeTabRefs received that moved index. The offsets in
the cloned formulas still count from the position that the source
had before the insert.
Pass the source position from before the insert instead, which is
the same one that CopyTab already gives to the range name copy.
This follows "sc: Fix backward reference when copying a sheet"
(Ie32d0ceac34525ccaf13aed8fb9630ae42d4225e), which fixed copies
placed after the source.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I063818265e0d56498bc9e09f04f85d3f5191b4d2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13662
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 2539d0afe0d68409f5e43b2d92c4d85b697566cd)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211515
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The reverted commit changed the way references are handled when
copying sheets in order to mimic how Excel behaves.
However, LibreOffice behaves differently (tested back to
LibreOffice 3.3) so the change might break the workflow of
many users (https://xkcd.com/1172/)
The proper way to address this would be by adding a new
config option, so users can choose how LibreOffice behaves,
but that needs to be implemented in a different patch.
This reverts commit 5cefed66bc.
Change-Id: I16636e80de52328ef4c89a11da899b9e33b6aa00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211421
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
seen on converting forums/xlsx/forum-mso-en4-237685.xlsx to xls and
doing a hard recalculation of the reloaded export, which aborts with:
soffice.bin: sc/inc/formulacell.hxx:514: void ScFormulaCell::MaybeInterpret():
Assertion `!rDocument.IsThreadedGroupCalcInProgress()' failed.
#11 ScFormulaCell::MaybeInterpret at sc/inc/formulacell.hxx:514
#12 ScFormulaCell::IsEmpty at sc/source/core/data/formulacell.cxx:3218
#13 ScRefCellValue::hasEmptyValue at sc/source/core/data/cellvalue.cxx:705
#14 ScInterpreter::Compare at sc/source/core/tool/interpr1.cxx:881
#15 ScInterpreter::ScNotEqual at sc/source/core/tool/interpr1.cxx:1162
#16 ScInterpreter::DispatchOpCode at sc/source/core/tool/interpr4.cxx:3852
#17 ScInterpreter::Interpret at sc/source/core/tool/interpr4.cxx:4414
#18 ScFormulaCell::InterpretTail at sc/source/core/data/formulacell.cxx:2274
#19 ScColumn::CalculateInThread at sc/source/core/data/column2.cxx:3270
#20 ScTable::CalculateInColumnInThread at sc/source/core/data/table1.cxx:2740
#21 ScDocument::CalculateInColumnInThread at sc/source/core/data/documen8.cxx:421
#22 Executor::doWork at sc/source/core/data/formulacell.cxx:5541
#23 comphelper::ThreadTask::exec at comphelper/source/misc/threadpool.cxx:320
lcl_InterpretSpan calculates the first cell of a dirty span with a
group call and the cells after it one at a time, and rechecks only
the cells it calculated one at a time.
The first cell can still be dirty when that call returns. The
dependency walk found a cycle, so the group was rejected, and that is
recorded on the group itself, as mbPartOfCycle and a meCalcState of
GroupCalcDisabled. Interpret then skips InterpretTail, so that only
the group which starts the cycle is calculated.
Both flags sit on the group that was rejected, while lcl_InterpretSpan
looks at the parent group. The bool it gets back says whether a group
interpret was done, not whether this cell was calculated, so the cell
has to be asked.
The rest of the span and the ungrouped cells have been checked for
exactly this since:
commit 4f36f2ccab
Date: Fri Sep 4 15:51:07 2020 +0200
detect if a cell still needs interpreting after Interpret()
so check the first cell too, and leave the group to the unthreaded
path when it was left uncalculated
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I3756ed54fbbb9caf48467e0faab5f5cdddb8e5da
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12674
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e685bd07146af13db00f6b6811b74d2eba297d80)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211379
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
document.hxx included drwlayer.hxx, and with it svx/fmmodel.hxx,
svx/svdmodel.hxx, svx/svdundo.hxx, svx/xtable.hxx and editeng/outliner.hxx,
in all 700 translation units that use ScDocument. The only place in the
header that needed the complete type was the inline destructor of
sc::DrawUndoGuard, which now lives in documen9.cxx next to
ScDocument::BeginDrawUndo. The ScObjectHandling enumeration, used as a
default argument of SetLayoutRTL, moves to types.hxx so that both headers
can see it.
The files that used the drawing layer or the svx model classes through this
include now include drwlayer.hxx themselves, and a few headers that relied
on the same chain for TranslateId, Idle or SvStream get the header or
forward declaration they need.
clang -ftime-trace suggests this is 6% of the sc build time.
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Change-Id: Id723c46ef0c881428ab1d9a2e9a642713a92e79e
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12681
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 3e8fd8cd92ff57aaef5ba9d4b71933700ee3f83b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211316
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
An empty cell as the search value found nothing. XLOOKUP(;A1:H1;A1:H1)
with the argument left out does find the first empty cell, but a
reference to an empty cell took the string branch in ScXLookup() and
searched for "" instead, so SetQueryByEmpty() was never reached and
neither the range nor the matrix search could match. MSO returns the
row of the empty cell.
A search value that is empty now sets isEmptySearch however it
arrives, from a cell reference, from an external single reference, or
from a matrix element under a JumpMatrix, in ScXLookup() and
ScXMatch(). ScMatch() keeps its own behaviour, it has no empty search
at all. lcl_CompareMatrix2Query() reports an empty element as equal
when the query asks for empty, which is what its TODO asked for.
The search also stops at the first empty element now instead of
running to the end of the vector, so an entire external column that
holds a thousand cached rows costs a thousand comparisons and not a
million. One such array formula went from 24s to 2s.
Note: a search value that is an empty cell now finds the first empty
cell of the search range, so a document that showed a #N/A there
shows the matching value instead.
Change-Id: I487b31bc5a4fe1edd35df14db0ae8f1548f7406d
Signed-off-by: Balazs Varga <balazs.varga@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12616
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 1903238df9d450e8a1d62f442af1967fcbf3f111)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211107
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
='file:///source.ods'#Sheet1.A1:A5 written in a row the range does
not cover showed the first cell of the range. A sheet local range
gives #VALUE! there, because DoubleRefToPosSingleRef() finds no
position and pushes nothing, while an external range went on to the
matrix path and the cell took the top left element of it.
Interpret() now sets NoValue for a range that the position does not
intersect, outside a matrix formula where the whole matrix is the
point. A document that cannot be reached reports its own error
before that, so an unresolved link still gives #REF! and not
a #VALUE!, which testExternalRefUnresolved checks.
MSO gives #VALUE! for =@'[source.xlsx]Sheet1'!A1:A5 in such a row.
Follow-up of commit: I68cc88b5bb533cfcd19537be6705e8a64834af64
(sc: take the implicit intersection of an external range)
Change-Id: Id619ec3285060ea42033ff2343ea7316f382c3d7
Signed-off-by: Balazs Varga <balazs.varga@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12615
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 895d3f3948cc7d407caaa0ebd7165ea48c44ec8c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211106
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
=@'file:///source.ods'#Sheet1.B:B showed the first cell of the
column and not the one in the formula's own row. ScSingleValue
leaves an external range on the stack unchanged, and Interpret ends
with it on the matrix path, so the result became the top left
element of a matrix over the whole range.
A sheet local range takes a position dependent implicit intersection
in both places, with DoubleRefToPosSingleRef. An external range now
does the same through PopExternalDoubleRefPushSingleRef, which reads
the position from ScCompiler::ExternalDoubleRefToPosSingleRef.
Where the position does not intersect the range nothing changes,
so an unresolved link keeps its own error instead of turning into
a #VALUE!, as testExternalRefUnresolved expects. The external and
the sheet local case still differ there (TODO).
Follow-up of commit: I3baf826177fbeeb4616f407d653f1457a2fbfa8f
(sc: don't build a JumpMatrix for an entire external column)
Change-Id: I68cc88b5bb533cfcd19537be6705e8a64834af64
Signed-off-by: Balazs Varga <balazs.varga@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12614
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 596a329b2f0e888047069b442f4da507a0c668f8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211105
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A file with XLOOKUP over entire external columns did not finish
loading. ConvertMatrixParameters turns a scalar Value parameter into
a matrix, and an external reference comes back at its full MAXROW+1
height, so every formula cell ran the function body over a 1048576
row JumpMatrix. It is not XLOOKUP only, every function with a
ForceArray parameter somewhere goes through that conversion, VLOOKUP
and MATCH among them.
The svDoubleRef case takes a position dependent implicit
intersection outside array context, and leaves the token for the
function that pops it to resolve with DoubleRefToPosSingleRef. No
function does that for an external reference, so svExternalDoubleRef
now resolves it, from the shape of the range.
DoubleRefToPosSingleRefScalarCase cannot do it, because it asks
whether the formula position lies within the range, which means
nothing across two documents.
Also in array context, where the JumpMatrix stays, an entire column
or row is trimmed to the data area first, like the svDoubleRef case
does with ScDocument::ShrinkToDataArea. The new
ScExternalRefManager::shrinkToDataArea asks the source document when
it is already loaded, and the cached ranges otherwise. Trimming on
its own does not help, because the JumpMatrix only shrinks to the
data extent and the body still runs once per row.
Change-Id: I3baf826177fbeeb4616f407d653f1457a2fbfa8f
Signed-off-by: Balazs Varga <balazs.varga@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12613
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 504cb9b329a5a4ce4f4c6ec53bde99c5e8c3de0c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211104
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Switch the method param to the XModel3 interface
from the very basic XInterface type. This drops
the need to explicitly cast/query to avoid
ambiguity in the callers where the passed object
multi-inherits the XInterface interface/base class.
This also prepares for switching the return type
of SfxObjectShell::GetBaseModel to a reference of
the concrete SfxBaseModel in an upcoming commit (without
introducing ambiguity due to multi-inheritance from
XInterface in places using only an XInterface
reference).
Change-Id: I97e060136b02f3eb1e652cff4021e57a85677e19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211052
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The earlier change only handled the simplest case of a list validation
that points at a name wrapping a table reference. A name defined as
MyTable[Column] still came up empty, and a table with a header row showed
its values shifted up by one, with the header as the first entry.
Match the name's leading token against a table reference instead of
requiring the whole body to be a single token, so column-qualified
references are handled too. Take the area from the reference the compiler
already resolved, which is the right column without the header and totals
rows, and fall back to the database range with those rows dropped when
the reference is not yet compiled.
Move the table-reference-to-area lookup into one helper shared by the
direct branch and the through-a-name branch.
Add tests for a numeric table with a header and for a column-qualified
reference.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I105fee3a677d5e982403562adc8f9a4e6bb94a25
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5531
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 4c9e6da406be75d90323e1728556a1cd3afbaa09)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210986
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
When a list validation points at a defined name whose body is a
structured table reference (e.g. MyTable[Column]), the dropdown
came up empty and the log carried "ScValidationDataList: Entry
not found". After this change the dropdown shows the values from
the referenced table column. No file-format or UI change, the
validation still saves back as the same structured reference.
Internally, ScValidationData::GetSelectionFromFormula only
recognised defined names that resolve directly to a cell range
(IsReference). A name whose token array is a single ocTableRef
fell through to the matrix path with no usable values. Unwrap
that case in the ocName branch by looking up the referenced
ScDBData and using its area.
Signed-off-by: Meven Car <meven.car@collabora.com>
Change-Id: Iac43a9c07a97f417fa914d8621ea5e6dd2f4ba85
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4297
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit d6fcdb0b3036833c725effbb7519f246862e2be7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207473
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The previously used IGNORE_CASE transliteration folded the German "ß" to
"ss", leading to a single entry in the auto-filter.
In addition, a copy and paste error in LessSortCaseInsensitive was
addressed, which affected the correct display order.
Change-Id: Ib05c6860f1c03986644a7237ee9701ffa16358b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210956
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
Unticking Diacritic-sensitive in Find and Replace changed nothing in
Calc, so a search for a word written without accents still passed over
the accented cells.
Before searching, Calc drops the Asian search options again when they
are turned off, and that mask threw away the two options the dialog
offers on their own as well. Keep those two.
Signed-off-by: Samuel Mehrbrodt <samuel.mehrbrodt@collabora.com>
Change-Id: I193af58f308a82b36093299d4fca6d10b0f87e52
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12079
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit adb304b3f04120adc9192aac6986b3b857af3af9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210648
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
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
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>
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>
Bayram Çiçek