Need help with "Progress indication" in WCX plugins

[rg_software]

I am working on a pseudo-packer plugin for converting audiofiles (similar to Audioconverter that we had to leave behind in 32-bit era).
One problem I faced is progress bar. I think I understand how to implement it, but there is one weird thing that is either my or TC bug.

When I run my plugin first time, the indicator works correctly. However, when I try to compress more files, it starts counting files as if the same session is continued. See, here it thinks that the first file in the second session is actually file #20:

Image: https://i.ibb.co/BfK952W/Clipboard01.png

I noticed the same behavior in Graphics Converter plugin, so I am puzzled. Any ideas?

[ghisler(Author)]

I assume that you use the callback function tProcessDataProc to show progress. Please note that you have to pass the number of bytes processed since the last call to tProcessDataProc, NOT the overall number of bytes processed!

[MVV]

Perhaps it would be better for a pseudo-packer plugin to use negative values that set progress bar position directly.

[rg_software]

Well, thank you for answers. I tend to believe that my code follows the recommendations.
I am setting the progress indicator to the number of bytes since the last call, and I also tried to set the initial indicator to zero using negative values.

When I pack some files, everything works correctly, and the issue appears only when I am trying to pack some more files. This makes me think that something is not reset between the sessions, and I don't know what I can do about it.

[milo1012]

Just some quick guess:

• do you check for a valid function pointer in SetProcessDataProc (INVALID_HANDLE_VALUE is defined as -1, or 0xFFFFFFFF (32-bit)- reason: TC calls SetProcessDataProc for PackFiles, without previous call to OpenArchive -> no valid hArcData available)
• did you make sure to use SetProcessDataProcW instead of SetProcessDataProc when creating a Unicode capable plugin?

From my experience, the only reason why TC might increment that counter is that you use different strings each time you call the progress function, as TC tries to keep track of the files you selected for compression (it fills a map of file paths, so that the counter doesn't increase when you "process" a file a 2nd time during the pack process). When writing the zpaq plugin I never had any problems using this function's logic. So I can only guess that you somehow either do too many calls to the progress function or you use varying strings for individual files, as the progress indicator itself seems to work, but the counter is wrong.

[Flint]

2rg_software
I tried to reply to the E-mail you've sent me, but the mail was bounced back with the "Unknown user" status. Also you did't enable any option of contacting you via the forum, so I have to write here. Please, send me a valid E-mail so that I could reply to you.

[rg_software]

Thanks again for these suggestions. I will try to investigate.

My basic presumption was that once packing is done, it is done, so the next packing session (select more files, then pack) has no knowledge whatsoever about the previous session. However, it is seemingly not true.

Some more experiments:
(select 3 files, pack) -> works as expected
(select 5 files, pack) -> starts with progress bar at 4/5 -- so it thinks that we are continuing the previous session, and 3 files are packed already.
(select 10 files, pack) -> starts at 9/10, then after 10 goes out of bounds.

So apparently something is not reset in my DLL between the sessions. What can it be?
Suppose in theory I want to start with progress indicator at 4/5 -- how do I achieve that (besieds passing four files size upon the first call to tProcessDataProc)?

[rg_software]

I am still slowly struggling with this function. May I ask for a hint on this point:
Where the number 33 comes from?
I mean, Total Commander calculates it automagically without my intervention. When I start packing it is already not zero. Where does it take it?
Image: https://www.dropbox.com/s/3dc00po5s5ckqsz/pack33.png?dl=0

[rg_software]

Hi all! After a long break I decided to get to the bottom of my issue.

To recap: I am writing a WCX plugin, and I face the following problem. When I pack 4 files, I get a progress indicator going from 1 to 4. When I pack more files, Total Commander starts counting from 5. I can affect the value of the progress bar, but the numbers showing the file progress (like 5/7) are displayed by TC, and are beyond my control.

I checked other WCX plugins and found that some of them have the same issue: for example, GraphicConverter and SetFolderDate. In contrast, zpaq doesn't. So I had to dig through the source code and find out what makes zpaq different, and I think here is the answer:

GetBackgroundFlags() must be implemented and must return a non-zero value (okay, zpaq returns "BACKGROUND_PACK|BACKGROUND_UNPACK", so I cannot really vouch for other function return values).

Perhaps this should be considered a bug in TC, but at least for now I can say that a packer should do this.