[reactos] 01/01: [RAPPS] Addendum to 0.4.15-dev-3724-g3a7c0d8 CORE-18018

[Joachim Henze]

https://git.reactos.org/?p=reactos.git;a=commitdiff;h=adfef37b2b299be9b31135...

commit adfef37b2b299be9b311356b763741603639cdff
Author:     Joachim Henze [e-mail]
AuthorDate: Sun Jan 23 21:21:50 2022 +0100
Commit:     Joachim Henze [e-mail]
CommitDate: Sun Jan 23 21:21:50 2022 +0100

[RAPPS] Addendum to 0.4.15-dev-3724-g3a7c0d8 CORE-18018

For a moment I thought this member was obsolete entirely,
    and intended to delete it entirely.
    (as its size is just ULONG which is too small for big downloads > 4GB size).
    It apparently works also without it to display the size,
    as we actually use a different member that stores the size as a string.

But there actually still *is* a usage for that ULONG representation.
    In (the rare) corner-case the http download does not allow to query the size,
    then the ULONG representation m_SizeBytes is used as a fallback for the
    download-progress-bar to avoid 'marquee mode'.

The 'fallback of the fallback' so to say.
    We should enlarge this to be a 64bit unsigned value some day.
---
 base/applications/rapps/available.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/base/applications/rapps/available.cpp b/base/applications/rapps/available.cpp
index ee37a2b975f..d2da0043f33 100644
--- a/base/applications/rapps/available.cpp
+++ b/base/applications/rapps/available.cpp
@@ -217,6 +217,7 @@ VOID CAvailableApplicationInfo::RetrieveSize()
     if (!m_Parser->GetInt(L"SizeBytes", iSizeBytes))
         return;

+    m_SizeBytes = iSizeBytes;
     StrFormatByteSizeW(iSizeBytes, m_szSize.GetBuffer(MAX_PATH), MAX_PATH);
     m_szSize.ReleaseBuffer();
 }