summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2020-11-20 08:06:40 +0100
committerStephan Bergmann <sbergman@redhat.com>2020-11-20 11:50:32 +0100
commit4fc0184aede43a48b458d1ecd2b9d07e8aa80d25 (patch)
tree05daefbd9d36d82a1c9f60f4b052a59197493467
parentb9c12f576a5ce0ff6e4fa0d313c0c11769de0b26 (diff)
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 <sbergman@redhat.com>
-rw-r--r--sc/source/filter/ftools/fprogressbar.cxx10
1 files changed, 5 insertions, 5 deletions
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;