diff options
author | Eike Rathke <erack@redhat.com> | 2022-12-13 21:46:23 +0100 |
---|---|---|
committer | Eike Rathke <erack@redhat.com> | 2022-12-14 00:05:36 +0000 |
commit | 7f5215e1514bcca114aaf0a2acfcc85dc676b67b (patch) | |
tree | b22bba2e934892620a3cc6e45561cb620ee2f0c8 /svl | |
parent | 25778012374b2f03cd01303c01d167206515ee71 (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.cxx | 5 |
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); |