summaryrefslogtreecommitdiff
path: root/svl
diff options
context:
space:
mode:
authorEike Rathke <erack@redhat.com>2022-12-13 21:46:23 +0100
committerEike Rathke <erack@redhat.com>2022-12-14 00:05:36 +0000
commit7f5215e1514bcca114aaf0a2acfcc85dc676b67b (patch)
treeb22bba2e934892620a3cc6e45561cb620ee2f0c8 /svl
parent25778012374b2f03cd01303c01d167206515ee71 (diff)
crashtesting: (assert) fix treatment of "#FMT" input line value
For "#FMT" test the original format type for not being NUMBER, the current format type may be different from finding an edit format. This constellation did not matter until commit 4fd1333ba4bb4f2311e9098291154772bd310429 CommitDate: Thu Mar 25 15:00:31 2021 +0100 tdf#140968 tdf#140978 XLSX import: fix lost rounded filters introduced the bFiltering parameter in which case the edit format is not used (and bFiltering is also set when collecting the filter entries for .xls export). In fact the logic should be changed such that obtaining the edit format isn't even executed in that case. For now just fix the "#FMT" case to be backported. Also, the bool return of SvNumberformat::GetOutputString(double,OUString&,Color**) does not indicate success or failure, but whether the "star" asterisk spreading was inserted or not. Contrary to SvNumberformat::GetOutputString(double,sal_uInt16,OUString&) ... cough. Change-Id: Ic8cbbd283a80c654a9ff22ea36897c9b72b8837d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144110 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit d5986b163276008d2a15a10f7de529d924b60d2f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144073
Diffstat (limited to 'svl')
-rw-r--r--svl/source/numbers/zforlist.cxx5
1 files changed, 3 insertions, 2 deletions
diff --git a/svl/source/numbers/zforlist.cxx b/svl/source/numbers/zforlist.cxx
index cfbce503941a..eb360c5b0ad6 100644
--- a/svl/source/numbers/zforlist.cxx
+++ b/svl/source/numbers/zforlist.cxx
@@ -1700,6 +1700,7 @@ void SvNumberFormatter::GetInputLineString(const double& fOutNumber,
* numbers so wouldn't be a safe bet. */
eType = pFormat->GetNumForInfoScannedType(0);
}
+ const SvNumFormatType eTypeOrig = eType;
sal_uInt16 nOldPrec = pFormatScanner->GetStandardPrec();
bool bPrecChanged = false;
@@ -1732,13 +1733,13 @@ void SvNumberFormatter::GetInputLineString(const double& fOutNumber,
ChangeStandardPrec(INPUTSTRING_PRECISION);
bPrecChanged = true;
}
- const bool bOk = pFormat->GetOutputString(fOutNumber, sOutString, &pColor);
+ pFormat->GetOutputString(fOutNumber, sOutString, &pColor);
// The #FMT error string must not be used for input as it would lead to
// data loss. This can happen for at least date(+time). Fall back to a
// last resort of plain number in the locale the formatter was
// constructed with.
- if (!bOk && eType != SvNumFormatType::NUMBER && sOutString == ImpSvNumberformatScan::sErrStr)
+ if (eTypeOrig != SvNumFormatType::NUMBER && sOutString == ImpSvNumberformatScan::sErrStr)
{
pFormat = GetFormatEntry(ZF_STANDARD);
assert(pFormat);