sc/source/filter/ftools/fprogressbar.cxx | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
New commits:
commit 4fc0184aede43a48b458d1ecd2b9d07e8aa80d25
Author: Stephan Bergmann <sberg...@redhat.com>
AuthorDate: Fri Nov 20 08:06:40 2020 +0100
Commit: Stephan Bergmann <sberg...@redhat.com>
CommitDate: Fri Nov 20 11:50:32 2020 +0100
Adapt ScfProgressBar to SfxProgress::SetState taking sal_uInt32
...since 5a6ab81651a98dd726ab7d40101dc81f62895fd4 "tdf#75280 Cleaning up of
sal_uIntPtr usage #2". mnSysProgressScale had been introduced with
2a7add76241d8a3de05e3d26689a2d16d8b92913 "INTEGRATION: CWS dr20", which
mentions
"2004/06/17 14:58:21 dr 1.3.320.2: #i27407# handle limit of SfxProgress
(ULONG_MAX/100)" though the referenced
<https://bz.apache.org/ooo/show_bug.cgi?id=27407> "Save default row format
to
decrease Excel file size" does not appear to directly mention any reason for
this particular change. However, prior to
dbdc29e499abf125b6d6f66de668bc60c88fe599 "INTEGRATION: CWS toolbars2"
SfxProgress::SetState did contain code that multiplied the passed-in value
(back
then of type ULONG) by 100, so it appears mnSysProgressScale was meant to
mitigate that. So even if the original motivation for mnSysProgressScale is
gone, repurpose it to address the mismatch between std::size_t (as meanwhile
used throughout ScfProgressBar) and sal_uInt32 (as meanwhile used throughout
SfxProgress).
Change-Id: I1448bcd7521c87079bc4e9afc5f2d9951fc67aee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106216
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sberg...@redhat.com>
diff --git a/sc/source/filter/ftools/fprogressbar.cxx
b/sc/source/filter/ftools/fprogressbar.cxx
index b46f36027e8c..89301c14da56 100644
--- a/sc/source/filter/ftools/fprogressbar.cxx
+++ b/sc/source/filter/ftools/fprogressbar.cxx
@@ -24,7 +24,7 @@
#include <osl/diagnose.h>
#include <tools/stream.hxx>
-#include <climits>
+#include <limits>
ScfProgressBar::ScfProgressSegment::ScfProgressSegment( std::size_t nSize ) :
mnSize( nSize ),
@@ -65,7 +65,7 @@ void ScfProgressBar::Init( SfxObjectShell* pDocShell )
mpParentProgress = nullptr;
mpParentSegment = mpCurrSegment = nullptr;
mnTotalSize = mnTotalPos = mnUnitSize = mnNextUnitPos = 0;
- mnSysProgressScale = 1; // used to workaround the ULONG_MAX/100 limit
+ mnSysProgressScale = 1; // used to workaround the SfxProgress
sal_uInt32 limit
mbInProgress = false;
}
@@ -89,10 +89,10 @@ void ScfProgressBar::SetCurrSegment( ScfProgressSegment*
pSegment )
}
else if( !mxSysProgress && (mnTotalSize > 0) )
{
- // System progress has an internal limit of ULONG_MAX/100.
+ // SfxProgress has a limit of sal_uInt32.
mnSysProgressScale = 1;
- sal_uLong nSysTotalSize = static_cast< sal_uLong >( mnTotalSize );
- while( nSysTotalSize >= ULONG_MAX / 100 )
+ std::size_t nSysTotalSize = mnTotalSize;
+ while( nSysTotalSize > std::numeric_limits<sal_uInt32>::max() )
{
nSysTotalSize /= 2;
mnSysProgressScale *= 2;
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
