CoinMPSolver did the whole job in one function: sample the model by
perturbing each variable, build the CoinMP matrix from those
coefficients, solve, and read the result back. Move the matrix
build and solve into a standalone helper, coinmpSolveLinearModel,
that takes the sampled coefficients plus the variable bounds and
column types and returns the solution and status.
The helper treats the first entry of each cell's coefficient vector
as the value of an affine model at the origin and the rest as the
per variable slopes, which is what the existing sampling already
produces. That keeps the same convention while letting a future
caller supply coefficients sampled around a different point and its
own bounds, which is what a sequential linear programming loop
needs.
No behaviour change. CoinMPSolver still samples and sets up bounds
and column types exactly as before, then calls the helper. The
CoinMP solver unit test passes unchanged.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I6d373a48caa9d67a932a599068368bae978f1f22
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4648
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 197f790a93880f56dd53db43e6bbb61c22ccfdc2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208337
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Somewhat surprisingly, it is very easy for Calc to report a selection
when the selection has actually been negated.
And sadly I didn't even see any examples in the code that checked.
ScViewFunc::SearchAndReplace early on calls
DoneBlockMode(true); // don't delete mark
which actually does delete the mark (if it has been negated).
So very quickly after HasSelection said that it did have a selection
this function cleared that status, so the rest of SearchAndReplace
operated on a no-selection state.
So ensure the correct state in srchdlg's TimeoutHdl_Impl
to prevent the user from requesting 'Current selection only'
when no selection is actually available.
Change-Id: Ifcafe251e68f036a25556cf5533d06337878d606
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208249
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
No Functional Change intended
This function is used very specifically for only UI stuff.
It is very different from any regular stuff.
So help to differentiate it by requiring the bool value.
To make sure I got all of them, I tested by requiring
a bogus OUString variable as well - make sure it compiled.
Change-Id: I4879427a806324d9fb9c033ef6b66ad24ba0bd54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208234
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This code is basically untouched since initial import.
For some reason, searching for patterns handled by Row
as if it was by Column - the opposite of text searching.
This patch fixes that.
Thanks to Julien Nabet who gave an initial try
and identified that looping again didn't work.
Change-Id: Ie6daa67e7d94bb1a5b8cd58158d20f1a383a7d77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208200
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes a LO 3.5 regression
from commit 0783e78de2
Let's avoid modifying the selection data during search and replace
The problem was that only the first sheet's range was used,
and it was being applied to every sheet that had a match.
(Thus one reason why selection data was modified during S&R).
I would have LOVED to have some functions like ScRange(SCTAB)
or GetIntersectedRange(SCTAB). I almost created this one,
but the compile took so long, and it needed ScDocument passed to it
which made it look ugly - so I didn't bother in the end.
Change-Id: I6abc25fd4f7002d190632fe33963fdeb1af4b1ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208231
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
If the user has edited a cell, but has not yet pressed enter
and then they start/resume a search,
then the change being made might be applied to a different sheet.
Yeah - so stop editing before doing a search, eh?
I excluded SID_SEARCH_ITEM because that is called every time
the dialog starts/stops, any checkbox is ticked, etc.
So excluded for performance/extreme redundancy reasons.
I can easily imagine wanting to use search when building a formula,
so let us exclude that case as well. (see tdf#137899)
Change-Id: I61b22e668c7080c4f1786e1a720b1c8b4bafa68c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208223
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
If you search by Row or Column forwards,
you will loop back to the beginning.
If you search by Row backwards,
you will loop back to the end.
This patch adds looping when searching by Column backwards,
and it also works when 'All Sheets' is checked.
Change-Id: I23252671b47fe05953cfd386a46b1c065d512127
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208204
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
The solver components reached every cell through the spreadsheet UNO API:
getSheets, then getByIndex for the sheet, then getCellByPosition, each with
a QueryInterface. That indirection is cheap once but expensive when it runs
for every variable on every evaluation.
Now that the solvers live in sc, recover the ScDocument from the document
through the UNO tunnel (ScModelObj) in setDocument and read and write cells
directly with ScDocument::SetValue and GetValue. Automatic recalculation is
turned on there as well, so writing the input cells and then reading the
recalculated objective and constraint cells behaves exactly as before. Both
the shared SolverComponent base (used by the CoinMP solver) and the
standalone SwarmSolver are converted.
The results are unchanged because the recalculation engine is the same. Only
the cost of getting values in and out of the document drops. The swarm solver
evaluates the objective for a whole population every generation, so this is
its hot path: on a 100-variable model its evaluation loop runs about four
times faster. CoinMP touches the cells only once, in a single pass that reads
off the linear coefficients, so it gains less, about 1.7 times faster on the
same model.
Library_solver now links sc and includes sc/inc. SwarmSolver keeps the UNO
cell lookup only for the uncommon case where a constraint's right-hand side
is given as a cell address.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I03ccec74cdc4d6cde30c86e048bf4314c3ca1397
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4047
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 929c17cf8e51a1510c32399de4a94ba946bb9919)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208281
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Copy the value from the status bar.
According to the checkboxes selected in the submenu.
If “None” is selected, choosing “Copy Value...” saves
an empty string to the clipboard.
This effectively clears the clipboard.
Support for multiple national languages has been added.
Change-Id: I662e8be8feaeac5bf2e4d69f557a8fec2420ff47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207385
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Relocate the whole solver component out of the standalone sccomp module
and into sc. This moves the SolverComponent base class, the CoinMP and
Swarm solvers, the differential evolution and particle swarm headers, the
UNO service registration, the scc string resource, and the two unit tests.
The now-empty sccomp module is removed.
The solvers are Calc specific. Moving them inside sc is the first step
toward letting them work directly with ScDocument, and eventually clone a
document or its sheets so trial calculations can run in parallel. That
direct access is only possible from inside sc, so the relocation has to
come first.
This is a pure relocation with no behaviour change. The translation domain
stays "scc" and its polocation still points at "sccomp", so the existing
translations keep loading unchanged. Re-homing the scc translation domain
into sc is left as a follow-up.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I5b972daae4c51f04ca394fc9a92f89ac0c4dd599
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3832
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 7f1bea8723761f97c053f2e7e46aab7081b1bb21)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208080
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
vcl::WindowData is used to manage/store various state
information for windows. It can be (de)serialized to/from string.
So far, both the weld::Window API to get/set window state
as well as the SvtViewOptions API were based on the string
representation.
Switch those and various related places to using vcl::WindowData
instead to use a stronger/more specific type than just OUString
in various places across the code base.
Do the string (de)serialization where necessary, but otherwise
prefer to use vcl::WindowData directly.
Calling weld::Window::set_window_state with a WindowData
param that doesn't indicate that anything should be set
(i.e. whose mask is vcl::WindowDataMask::NONE) should
have no effect, so drop extra checks that were previously
checking whether the string representation was empty
and skipping the call to weld::Window::set_window_state in
that case.
No change in user-observable behavior intended or
seen in a quick test.
Change-Id: I5bc4caeb49d0ab2bbc4fa597a5ef19d86d3aac2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208125
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The SvtViewOptions class is used to store the state
of windows/dialogs.
So far, SvtViewOptions::SetWindowState and
SvtViewOptions::GetWindowState are string-based
and the callers are responsible for (de)serializing
the vcl::WindowData to/from string.
This will be changed to become the responsibility
of SvtViewOptions in an upcoming commit.
Since unotools is below vcl in the module
dependency chain, it cannot make use of vcl,
i.e. vcl::WindowData couldn't be used there.
Therefore, move SvtViewOptions from unotools
to svtools, which is above vcl in the module
dependencies.
(svtools/README.md summarizes the purpose of the
module as "Tools on the Top of VCL", which seems
an appropriate place for helper code to manage
the state/options for dialogs, tab pages,...)
Change-Id: If849224c35c7ac895659ddb7c17e6d17061d61a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208124
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The Lpsolve solver and the CoinMP solver are both used for the same
thing: a linear model, with optional integer variables by branch
and bound. CoinMP (CLP plus CBC) is the more capable and better
maintained of the two, so the lp_solve one adds a second bundled
dependency and a parallel copy of the solver code for no capability
the other lacks.
Remove the LpsolveSolver component, the bundled lp_solve external
(and its colamd dependency, which only lp_solve used), and all the
build, configure, packaging and license references to them.
A document may still name com.sun.star.comp.Calc.LpsolveSolver as
its engine. SolverSettings now reads that name as the CoinMP
solver, which solves the same model, so such documents keep
working.
The Calc solver test that exercised the engine now uses CoinMP. Its
knapsack model has a single optimal total value of 6987, which fills
the weight capacity of 1000 exactly and which CoinMP finds. The
lp_solve run had returned a suboptimal 6981, so the test now expects
the true optimum.
The build setup changes only take effect after re-running autogen.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia14d8c491779873da6b0157aa524056275adf8f5
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3810
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e77738a7ca7d44fd9d1f852e26d46e3a6d60467b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208038
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Concatenating two matrices of different sizes gives a result the size
of the larger one.
Each operand was read across the whole result. The shorter operand
has fewer cells than the result, so the read ran past the operand's
end and went out of bounds, which crashed. Now each operand is read
only within its own size.
A cell that only the larger operand covers has no partner in the
shorter one to join with, so it stays empty.
a problem since:
commit b4957ed105bcaa4a73666a6a5e119d523284b0c9
Date: Sat Jun 27 19:26:56 2026 +0900
sc: extend mismatched-extent matrix arithmetic to the longer side
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I0ae4a0b71a846bb88383cd1cb472a022895ae14a
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6696
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 645e103b914f07f80c0c425fb1b3262e5e4f1648)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208007
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Interpreting a callable consumes its arguments off the interpreter stack
and must leave exactly one result token behind.
Two paths returned without pushing anything: a lambda whose result was
empty, and a macro whose arguments could not be built.
Each such call left the stack one entry short, so a later token read
past the stack base. That surfaces later as the "underflow" abort in
Interpret, and as the matrix count mismatch in ConvertMatrixParameters.
Push the error, or an empty result, on those two paths.
crash converting forum-en-34250.ods to xlsx:
#21 ScInterpreter::Interpret at sc/source/core/tool/interpr4.cxx:4328
#22 ScFormulaCell::InterpretTail at sc/source/core/data/formulacell.cxx:2201
#24 ScFormulaCell::GetMatrix at sc/source/core/data/formulacell.cxx:3267
#25 ScInterpreter::ScMatRef at sc/source/core/tool/interpr5.cxx:3764
#26 ScInterpreter::DispatchOpCode at sc/source/core/tool/interpr4.cxx:4050
#27 ScInterpreter::Interpret at sc/source/core/tool/interpr4.cxx:4333
#30 ScFormulaCell::MaybeInterpret at sc/inc/formulacell.hxx:515
the same problem also aborts in ScInterpreter::ConvertMatrixParameters
at sc/source/core/tool/interpr4.cxx:1555.
since:
commit 837cf12bc45c72e08c4629d07a43c27763b263b2
Date: Sat Jun 20 23:28:17 2026 -0400
Implemented callables as first-class objects in Calc formulas
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I46a9fa77872ac1c540f9b0904da2e3f9397e71c9
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6153
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit f239eafadbb1c539d0c6dfbb459ca25bc10b7456)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207976
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
PutMatrixValue cloned the referenced cell's formula result token for a
single, double or list reference, but a reference can point at an ordinary
value, string or empty cell, where ScDocument::GetFormulaCell returns null
and cloning its result token dereferences null. Read the plain cell value
into the matrix in that case.
crash finalizing an xlsx import (forum-mso-en4-792534.xlsx):
#0 ScFormulaCell::NeedsInterpret (this=0x0) at sc/inc/formulacell.hxx:487
#1 ScFormulaCell::MaybeInterpret (this=0x0) at sc/inc/formulacell.hxx:501
#2 ScFormulaCell::CloneResultToken (this=0x0) at sc/source/core/data/formulacell.cxx:3236
#3 ScInterpreter::PutMatrixValue at sc/source/core/tool/interpr5.cxx:1285
#4 ScInterpreter::ScByRow at sc/source/core/tool/interpr5.cxx:1521
#5 ScInterpreter::DispatchOpCode (eOp=ocByRow) at sc/source/core/tool/interpr4.cxx:4090
#6 ScInterpreter::Interpret at sc/source/core/tool/interpr4.cxx:4371
#11 ScCellFormat::GetString at sc/source/core/tool/cellform.cxx:90
#19 ScColumn::GetOptimalHeight at sc/source/core/data/column2.cxx:950
#24 ScDocShell::UpdateAllRowHeights at sc/source/ui/docshell/docsh5.cxx:450
#25 oox::xls::WorkbookGlobals::finalize at sc/source/filter/oox/workbookhelper.cxx:665
since:
commit e95c50471e6553f04ec814184456c50209a7e970
Date: Sat Jun 20 23:53:18 2026 -0400
Implemented functions which rely on callables
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Iadede9c4c75e9d1ee79fe2156d356389827595d6
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6151
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 0abe27b56512e1d524e23f1b759d9647cba85a87)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207975
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
ScLet and ScLambda read the parameter-name token's string without checking
GetType() first, so a token that isn't a string name faults on load, e.g.
forums/xlsx/forum-mso-en4-789942.xlsx:
#0 rtl::str::acquire (pThis=0x20d) at sal/rtl/strtmpl.hxx:735
#6 std::vector<OUString>::push_back
#8 ScInterpreter::ScLet at sc/source/core/tool/interpr1.cxx:10938
#9 ScInterpreter::DispatchOpCode (eOp=ocLet)
#13 ScFormulaCell::MaybeInterpret
#15 ScCellFormat::GetString
#17 ScColumn::GetRangeScriptType
#24 GetOptimalHeightsInColumn
ScLet used to have this check until it was rewritten, the new ScLambda
never had it, since:
commit 6ad6aebb83305608788c878909cd77c29b298271
Date: Sat Jun 20 23:50:39 2026 -0400
Implemented LAMBDA and ISOMITTED for Calc
use the same fix as:
commit 4f5764a223f86ceea1eca70cbec55eb8aebea1f3
Date: Tue May 5 11:45:29 2026 +0100
crashtesting: fix ScLet/ScMatch/IterateParametersIf[s] crashes
Add a GetStringNameToken() helper for this and use it in ScLet, ScLambda
and the dynamic_cast calls in callable.cxx.
see also:
commit 65da502b7b40bd3bcad0cfd146716e815c72d48d
Date: Thu Apr 16 12:31:01 2026 +0200
reduce virtual calling in String*Token
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I7ce591bf5e53538aa947fafa9607b7339d715aaa
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6107
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 8b1f9cc417d914d72ea223815e8306bcb07299ec)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207977
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The OOXML format writes a built-in function that is passed as a value,
rather than called in place, with the _xleta. prefix, for example when
it is handed to a higher-order function or a LAMBDA parameter. Calc did
not recognise the prefix, so the function name did not resolve and the
reference was lost.
Strip the _xleta. prefix in the opcode lookup so the plain function name
resolves. The compiler already turns a function name that is not
followed by a parenthesis into a callable, so the value can be called
later with no further handling.
Add a test that imports COUNT passed as a value to a LAMBDA parameter
and calls it on an array.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I86ef5b71bb4e7cc655cb758dfc5d75caf74e5251
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5783
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit aa314fffc0ef133430e820a6d3b0ef784e20e6ee)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207892
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The OOXML format marks an optional LAMBDA parameter with the _xlop.
prefix in the parameter list, while the body refers to the same
parameter through the _xlpm. prefix. Calc recognised only _xlpm., so an
optional parameter kept its prefix, did not match the bare name used in
the body, and lost the mark that made it optional. It failed to bind,
and a call that left it out reported an error.
Recognise _xlop. as a parameter marker and strip it to the bare name, so
the declaration and the body references match. Carry the optional mark
onto the parameter token so the compiled code treats it the same way as
the native square-bracket form.
Write an optional parameter back with the marker the grammar uses: the
_xlop. prefix in OOXML and square brackets in the native grammars.
Add a test that imports an optional parameter in the OOXML form and
checks that ISOMITTED sees it as omitted and that concatenating it
yields the other operand.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia1df0fa6ca498f4c607507b3a865b3b367e5c11a
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5782
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit f198d7a984654aabd5e988d3c327da5552bc68e0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207891
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
When a double operand carries a boolean tag, string concatenation
renders it as TRUE or FALSE. The check for that tag used the resolved
stack type, which also reports a double for a missing argument or an
empty cell, and then read the tag from the operand as though it were a
double token.
Check the operand's own token type first, so the boolean tag is read
only from a real double operand. A missing argument or an empty cell
concatenates as an empty string.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I0da982b709fd968dd61e6b935979358cc8db8bab
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5781
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit ee2ca5da39bb81402b83f1cef7730c62adeffb12)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207890
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
LAMBDA now supports optional parameters with the [name] syntax; all
such parameters must appear after all required parameters in the
parameter list.
Optional parameters use svMissing, for compatibility with ISOMITTED.
Change-Id: Ice026eeb6937dadd3b1ffd8c07e0d3ce88de9afc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207392
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
CopyFromClip() recreates a named table the copy fully covered so the
structured-reference tokens in the pasted formulas can resolve
against it. It ran that step for any content paste, so a values-only
paste also registered the table, with its autofilter and style, even
though it carries no formula that would reference the table.
Gate the table recreation on the formula content flag, so a
values-only paste leaves the destination without a table.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I8bf7b30ef4fc415229d05f57955ac9d6cf65910e
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5097
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
(cherry picked from commit c0ec48adf51d34a50469b78df4136aaaa1dce074)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207946
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
CopyToClip() copies named database ranges into the clipboard document
through CopyDBsToClip(), which decided whether to carry a table by
testing it against the bounding box of the copied area. For a
non-contiguous selection the bounding box also covers the gaps
between the selected ranges, so a table sitting in such a gap was
carried even though none of its cells were copied.
Test the table against the actually copied ranges instead of their
bounding box, so a table that lies entirely in a gap is left out.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I1c8663e5190247dae0edf3878efe37186a7f6a4d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5095
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 37543af628671f723c9a661e2add91d6bc641591)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207944
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Switch the weld::Entry and weld::TextView handlers
that are called when the text changes due to user
interaction to pass a weld::TextWidget& param
instead of a weld::Entry& and weld::TextView&
one respectively.
Adjust related methods across the code base accordingly.
This unifies the behavior for both of these
weld::TextWidget subclasses and prepares for
deduplicating the logic and moving it to the
common base class in an upcoming commit.
That will also ensure they stay in sync.
(Change also motivated by the fact that their behavior was
differing before
Change-Id: I03d2a13cd84d53d806eb9e363f49c4b6be28d938
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 9 13:08:58 2026 +0200
tdf#130857 weld: Don't signal about programmatic TextView text change
.)
Change-Id: I5572fc88caf577fae9a23a39f1ec4f2179935a99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
A cut paste can add a named database range to the destination
document, just as a copy paste can, when the clipboard carries the
range and the destination does not yet own it.
ScViewFunc::PasteFromClip() forced the database-range snapshot for
a copy paste so that the addition could be undone even into an
empty collection, but the cut-paste branch built its ScRefUndoData
without that flag. Undoing a cut paste that added the range
therefore left it orphaned over the now-empty cells.
Compute the force flag once from the clipboard's named ranges and
pass it to ScRefUndoData on both the cut and the copy path.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ic942f722c89b9a2e34b4d83345e16f123a775848
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5094
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit ed7fbe013519bf313c7d2bf12166938872b77b75)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207943
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
CopyDBsFromClip() re-anchors a fully-copied named table at the
paste location with MoveTo(). Changing the area resets the table
column names, because the header range moves, so the names the
clipboard copy had carried were discarded. A structured reference
could then no longer resolve a column by name against the pasted
table, and its value became #REF!.
Save the carried names before the move and set them again
afterwards. The paste is a pure translation, so the names map to
the same columns as before.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ib5e836daa4c9739b38fd4fa8c8dc3d58c6793b75
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5092
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
(cherry picked from commit 5f08075266d8337a91f0ed3c3f4a1a18d81d03d8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207941
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The method is the handler set for ScTpUserLists::mxEdEntries
via weld::TextView::connect_changed and not called any other
way, so can never be called with a different weld::TextView
for the param.
Change-Id: I020ca2eb2b1bcf7a60a63ee467b605e521b65e70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207924
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Don't modify the input OUString param, but use an input
std::u16string_view param and return the new string instead.
Also switch the ScTpUserLists::AddNewList and
ScTpUserLists::ModifyList OUString params to
std::u16string_view, as mandated by loplugin:stringviewparam.
This simplifies both callers, which only create a string
copy to pass that as the in/out param.
Change-Id: I5bed126cf08e44418e9a5839ee70b64932f08a87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207923
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop ScTpUserLists::m_aStrCopyList and only translate
the string when needed: when the dialog using this
string as its title actually gets triggered.
The dialog can be triggered like this:
* start Calc
* insert something into cells A1:B2
* select cells A1:B2
* "Tools" -> "Options..."
* "LibreOfficeDev Calc" -> "Sort Lists"
* press the "Copy" button
Change-Id: Ic373ab375411e3fd85a6733e94179a415ddc21ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207920
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Without this, Qt Creator shows this error/warning
when opening the header:
tpusrlst.hxx:49:27: No member named 'TreeView' in namespace 'weld' (fix available)
(Probably not a problem during the build because of
the header only being included after other includes
that provide weld::TreeView transitively, but that
shouldn't be necessary.)
Change-Id: I4c542fa025dd4fb71e15ea9bab181954a12c853b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207914
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The XLSX f-element stores the spilled-range operator as the
prefix call _xlfn.ANCHORARRAY(<ref>). The compiler did not
know the wrapper, so _xlfn.ANCHORARRAY(C2) + 10 imported as a
name error.
Map _xlfn.ANCHORARRAY to ocSpill in the OOXML symbol table so
the wrapper compiles to the same RPN as <ref>#. A new
liftAnchorArrayToPostfix pass then rewrites the source-order
parse array to <ref># so the cell reads back as <ref># in the
formula bar.
Token-level tests cover the lift on a bare reference and an
arithmetic composition, and a file-import test loads an XLSX
fixture to confirm cells read back as # inside UNIQUE and SUM.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I687150ac0bb26d02ced9297dc2039c15655d5c0a
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5788
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 91e9a978c85458dc5a7c557588da1c402bc43887)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207906
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
A # spilled-range reference evaluates to a matrix that
ScIsFormula did not recognise, so ISFORMULA(B2#) returned a
single FALSE instead of the per-cell result a plain range
gives.
ScIsFormula now treats a range-carrying matrix like a range
reference, as the @ operator and ISREF already do. In an array
context ISFORMULA(B2#) matches ISFORMULA over the spill range,
and in a plain cell it reduces to the row-aligned cell.
Change-Id: Iceabe9d9a3ae72219291f8c7bf6986d355d8336a
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6264
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit e0e6eb3c11380b6787a96c1f6fccfb3d6722022e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207905
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tomaž Vajngerl