... like it's often the case in named expressions.
Wonder why that didn't pop up earlier..
Change-Id: Ie9d2b8642848981f420e45c6ede995f86e062903
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182318
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
... and top left / bottom right point to a single cell, so $K$9:K9
remains expandable to $K$9:K10
Change-Id: Ibafd1f715ae72de21d268e934ffd82df9a48f625
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182313
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Which isn't exactly needed because compiler uses
RID_STRLIST_FUNCTION_NAMES_ENGLISH_OOXML but the mapping is used
for css::sheet::XFormulaOpCodeMapper even if that is almost (?)
dead in Excel context. Gave warnings like
warn: sc:566679:566679:sc/source/filter/oox/formulabase.cxx:1381:
OpCodeProviderImpl: :initFuncOpCode - no opcode mapping for function ODF 'ORG.OPENOFFICE.EASTERSUNDAY' <-> OOXML '_xlfn.ORG.OPENOFFICE.EASTERSUNDAY'
Change-Id: I0e7a74ef24fd03bd533b486bd11dab1f6287e2c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179262
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
In fact do not accept anything else than blanks after integer
portion for a fraction.
Change-Id: I29746bb7cd78ecc6a7810e8841bee748589a36e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177899
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
... if at least one of the sheet names has to be quoted, instead
of 'Sheet1':'Sheet2'!C4:C4 where 'Sheet1':'Sheet2' is more logical
but not understood neither by Excel nor was it by Calc. A single
C4 instead of C4:C4 is more cosmetical.
Accept both forms now when reading OOXML documents to be able to
read back such broken expressions.
Change-Id: I228e458e2e3af387d9f89900fcfc16ab89757bae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175514
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
... and have inherited {sat-IN} as well as {sat-IN} locale data was
introduced for tdf#154987 and may have been used by documents since 7.6,
but {sat-IN} originally was meant for Devanagari script, as translations
show.
Change-Id: I7618d061b3eefa1ad2d49f97c9c1198361c8de36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174903
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
As this needs to be resolved for every occurrence of the function
name during export to OOXML and .xls and Add-In authors tend to be
lax with en-US vs en-GB, also because function names usually don't
differ, and use "en" at least in DisplayName.
Change-Id: If0b1b60c4806028c76296e5feaa74e7ddb307bb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172735
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Must be first "en-US" (preferred) or "en" or any first if no "en-US" nor "en".
Change-Id: I1549d6650b19fbb37952bd093692bbbcba1420c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172603
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
... to avoid temporary maps through base class
formula::FormulaCompiler::GetOpCodeMap().
Change-Id: I372355b57326eab00d4ccde651df4d0fe69166c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172588
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
... otherwise the unotools/source/config/configitem.cxx
ConfigItem::impl_packLocalizedProperties() checking for
(getValueTypeName() == "com.sun.star.uno.XInterface") would not
hit and thus not pack the properties, returning just the useless
XWeak pointer as property.
This in ScUnoAddInCollection::ReadConfiguration() lead to English
names not being extracted from configured Add-Ins' DisplayName or
CompatibilityName, nor any CompatibilityName added to the list.
Fallout from
commit bc70f674c2
CommitDate: Sun Jun 18 08:41:27 2023 +0200
Use getXWeak in configmgr
Change-Id: Ibaab8c08a06113b27ceffe1c45ef548c1d6fa225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172476
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
... of FormulaToken that's only created to extract a range from an
expression because that OOXML import part doesn't know to operate
on a ScTokenArray.
Change-Id: I4011723b682c3eae0e1c8d8e768553154c024061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171516
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
which is the case for all English function names, but not the
TableRef item specifiers like #All, #Data, ...
Change-Id: I7f675e05b0d52eac9596b96b4d2cf299351fb82a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171022
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
It's unnecessary to obtain system time twice or thrice and also prevents
different today values when looping over midnight.
Change-Id: Ifcf4917769bb1d853e326049711e295d54408eef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170699
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
* Update helpcontent2 from branch 'master'
to 95755ff59d2fc074796f341d2dc781660c52ce74
- Tip link to INDIRECT wiki page
Change-Id: I53d0bb0932617785ff64adc84c890d0be115125f
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/168578
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Also push error and bail out early if there was an error, or more
important pResultMatrix is nullptr.
Change-Id: I1094ed9d14795ea1bc3f4ff61d687cc28d0b94fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168300
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Which is the case if the actual format code is in an
x16r2:formatCode16 attribute that isn't handled yet.
Change-Id: Id35e774f8ccb167af2a46a8cc0f7611da76d708c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168232
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
That always was "result: 0, expected: 0" because it created a
number from string.
Also, while it looped over all sheets starting with the second,
values were always obtained from the second sheet.
Change-Id: Ib2d2a51d757c12fd9cd2a76b0b194c2112747e62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168107
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
API grammar (old GRAM_PODF_A1) here was always wrong and could
never had matched the formula string obtained from the document,
but in earlier days array separators weren't configurable so this
may have worked accidentally.. Likely GRAM_PODF_A1 was introduced
being confused by existance of older bApi parameter that never was
true though and got eliminated later.
Change-Id: Ie77ad4047c21d999bea1ff97c7c2b451f01121eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167844
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Same as for rtl_math_StringFormat_Automatic we want to preserve
the highest accuracy of integer values also with
rtl_math_StringFormat_G if nDecPlaces is large enough, instead of
possibly rounding into 15 digits. This occurred with
FastSaxSerializer::write(double) but rtl::OString::number(double)
and rtl::OUString::number(double) and rtl_math_doubleToString()
and rtl::str::valueOfFP() and rtl_str_valueOfDouble() and all
places calling with rtl_math_StringFormat_G are similar affected.
Question might remain why those places use
rtl_math_StringFormat_G with fixed nDecimalPlaces calculated from
RTL_STR_MAX_VALUEOFDOUBLE - SAL_N_ELEMENTS("-x.E-xxx") + 1
instead of rtl_math_StringFormat_Automatic with
rtl_math_DecimalPlaces_Max.
Change-Id: Ib388b119faed441c9020dca803649a4089da5b07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167647
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
The leading # digit before the separator was omitted. This never
worked as intended.
Change-Id: Idf8a6cf246b8db4e6d5361bc1c5f66c1c0c057c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166072
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Such that they are added to the top of the list after "[None]" and
only if "[None]" was requested.
{mul} and {und} ISO codes.
Change-Id: I024311fe7d638124932a1d38759305e8efec5962
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166012
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
... introducing a real fix.
commit 94ca402cd1
CommitDate: Tue Jul 25 15:04:01 2023 +0200
tdf#156174 sc DBData: fix regression of database ranges
just cured a symptom by removing a condition that shouldn't had been
removed, instead of getting to the real cause of an odd reference
update.
Shrinking the end of a sheet reference range and thus moving it one
before the previously referenced relative position is only possible if
the deleted sheet actually touches the referenced range, which here the
start value points to and thus checking ref>=start+delta is not
necessary and subtracting 1 even harms. This is different from deleting
columns or rows where the start value points behind the deleted area of
moving the following area.
Change-Id: If9ae5dd6f6ae5cd248ad5d999f1aa7577d4ec035
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160374
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Also, the CPU identifier for MSVC WIN32 is not X86 but INTEL, so
actually use SSE2 there as well, which was the cause of things
failing on that platform.
For other platforms than Intel x86/x86_64 SSE2 is not defined, so
exclude the new unit test based on that and live on with the old
slightly off value. Experiments did not yield any solution that
works, even using plain sumNeumaierNormal() (similar to SSE2) in
the executeUnrolled() case instead of KahanSum with its m_fMem did
not help, nor trying to add the internal values in different
orders or with long double, au contraire the error was slightly
larger.
Change-Id: Ica0b2963f76c01f248799e9a809ef06eb099e722
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156899
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to 379510d74d95dd4e7878e8e86401a3b60a6ef107
- Follow-up: tdf#152412 Re-add the note to the STYLE() function
... to not use it without reason..
This got lost with
commit 20d4c17ca1fb161bf5fccf3d94db93b0a4d322f2
CommitDate: Wed Jan 11 00:09:58 2023 +0000
tdf#152412 Improve the STYLE function help page
Change-Id: I48b11d8360a0a95ae1a76e4d0a339b5fe6488d2d
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/157835
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
When summing mixed formula cells and numeric cells, cell type runs are
summed using KahanSum that when switching cell types are added. Using
add() to explicitly add the rhs m_fError compensation value separately
may had lead to effectively cancelling out the relation of sum and
error, living on with an unrelated error value. Instead, add a "final"
rhs sum+compensation.
Change-Id: I751d3e0eeef9cd80482895c24f05b1ab667c3020
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156253
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
In case of failure to show failure details sc/qa/unit/functions_test.cxx
FunctionsTest::load() assumes result in A, expected in B, check in C and
formula in D.
Change-Id: I48d9e123664da314a1f7791f949d89569150b0c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156346
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
So we can actually find a detail if there are empty rows and not
just bail out with "Sheet2.A1 '' result: 0, expected: 0" or such.
Change-Id: I163f84edebfb98f6f0351ba3dc889d3fab0e6789
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156344
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Instead of # ##0,00 and similar it used # #0,00 that probably went
unnoticed since ever because it generates an expected display
string using the group separator at the right position; editing
such format yielded the format code ##0,00 with the group
separator flag set.
Change-Id: Id6ebb533f43a49a9aea1dd9ba87230e5d59901ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155114
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
... and repeated Date::operator++/--() that each calculate
lcl_DaysToDate( GetAsNormalizedDays() + 1 )
where Date::AddDays() does it once.
Also, that probably never worked correctly with negative time results >=24h
Change-Id: Ic67aaa3d93e0d6533501d52671acf765e2d9bbdd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151984
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Also keep explicitly given sheet reference relative to the same
sheet as user wished.
Affected only when moving formula cell position like with
cut&paste and drag&drop.
Change-Id: I6b1da6aea58b88a24567189ef6aa212dab01de49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151845
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Apparently a legacy leftover; it's perfectly valid to remove
EDITATTR along with CONTENTS, i.e. in Cut.
Change-Id: I10010e1fc98b5e5863d041d72ddf78d499a0ec45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151846
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Various operators were omitted so for an expression using only
such like '~' range "union"/concatenation the ranges weren't
highlighted; also use indexOfAny() instead of repeated indexOf().
Change-Id: I288bb8e0a2bf738bbc3a56025474a18ea18a4d13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151297
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
... instead of only ValidColRowReplicated(), and check the return
value. With this, the abort wouldn't had happened but an empty
string returned for this case (which would had been wrong as well,
but the caller has to check dimensions).
Change-Id: I75218c479896893146b0e73d3c82215fe61cdf6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151235
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Temporary measure until the actual cause is fixed.
The by string query of binary search on sorted cache is broken for
mixed types like here the numeric date cells and text cells.
Change-Id: Icfe0b0c30987fcefdd6ed11066ea9113f3b4dabe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151074
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Eike Rathke