Could file copy show the bytes copied so far?

[alank2]

I know the original winfile did not have this, but it is probably the one reason I go back to using explorer instead. A nice bar graph would be the best under "To:" in the "Copying..." dialog. Even a xxx KB of xxx KB would be great.

[schinagl]

No this is not possible with winfile.
It does not know ahead of the amount to be copied, and has no internal infrastructure for doing this.

[alank2]

Is there the possibility of a simple KB copied so far indicator?

[schinagl]

Sorry. Winfile internally does not know of any size of files during the copy loop.
Even this would be a significant change.

[alank2]

No worries; I thought I'd ask! Thank you!

[malxau-msft]

I agree that scanning the files to determine the total in advance would be a big change, and personally don't see much value since the resulting estimates aren't very accurate. Reporting what copy is doing is a smaller change with less runtime overhead; Winfile is already using CopyFileEx which has a callback function that reports the number of bytes copied, so it just requires connecting that back to the progress dialog.

Here's a quick-and-dirty proof of concept:

malxau@eb848ec

There's a lot missing here:

• As the screenshot shows, it really should change units based on device performance
• It's not localized at all, only one language dialog is updated and the text itself seems like it should be localized
• The dialog is used for other operations than copy, which perhaps deserve a smaller dialog, or maybe a different way to report progress (number of files operated on?)
• The logic should be more connected with Notify which redraws the file names, particularly if non-copy operations update based on file count

But it seems like a feature that could be done if there's value in it.

[schinagl]

I doubt there is value in it.

If you do this the next will say: this is lame, Explorer does it better and suddenly you are in a race which winfile never can win. There are so many aspects as you mentioned and It will always look outdated.

So Explorer has its values and winfile is at it is.

[malxau-msft]

I agree with that concern. Even aside from Winfile vs. Explorer, note that Explorer keeps changing this logic - the qualitative nature means whatever exists can always be modified to be better in a way that never ends.

That said, I tried to look further into what would be required to make this "real." One area of complexity not captured above is that progress is reported in DMSTATUSDLG (above, used for drag/drop) but also MOVECOPYDLG/DELETEDLG/MAKEDIRDLG for menu driven operations. The Notify function documents this at the top, but at the end of the function, another developer seems to be rhetorically asking which dialog it's for before doing something that's only correct for DMSTATUSDLG. Both comments were added in Windows 3.1, although the first was a few months earlier than the second.

I'm a bit curious how this all happened. Perhaps the motivation was UX (they didn't want to dismiss one dialog, flash up a second somewhere else on the screen, only for it to close momentarily.) Or perhaps the motivation was technical (they didn't want to allocate stack to support two recursive calls to DialogBox, which would need to be allocated for the lifetime of the process.)

Either way it sure is frustrating to have 8 languages with 4 dialogs per language to consider.