+[8.50b5] Background copy not aborted on TC exit

[gdpr deleted 6]

I think the main problem here is Windows API function that calls TC callback function sometimes to report progress, so we need to wait until it will call it again to tell it to cancel operation.

No, what i meant was along the lines of reusing the code that is already there to cancel the copy action if you close the bg copy window with the [X] button. An abort through this functions properly. There should be no additional trickery with a progress callback required.

[MVV]

If you're using API that supports callback, the only correct way to cancel operation - to return corresponding result in callback function (and it is what TC does when you cancel operation). But we need to wait until it is called.

[gdpr deleted 6]

If you're using API that supports callback, the only correct way to cancel operation - to return corresponding result in callback function (and it is what TC does when you cancel operation). But we need to wait until it is called.

Okay, gotcha.
But even if you copy very large files, the time until the next callback occurs should be within seconds. Unless i am wrong about this, there should be no reason for TC to enter some kind of wait state, just let it close. (Ofcourse, make sure you return PROGRESS_CANCEL in the progress callback when it is called again, otherwise the issue will remain...).

Although it might take a few seconds to delete the file fragment for USB sticks, you cannot soft-unplug the USB stick until this is finished anyhow.

[MVV]

With slow devices delay may take more than a few seconds... Anyway TC should close its windows and tell background threads to cancel and wait for their answer in background.

[gdpr deleted 6]

With slow devices delay may take more than a few seconds... Anyway TC should close its windows and tell background threads to cancel and wait for their answer in background.

I am a bit off-topic now, and i apologize for that.
How slow are those slow devices you are speaking about?
I have here some pretty old crusty slow 2GB-USB stick which has a hard time managing net write speeds beyond 1MB/s (even worse when you copy many small files). But still, deleting a file is within 1..2 second.
Since cancelling only involves deletion of only one single file (that which is currently being copied), deleting it could not really take significant time, since deletion does not result in that many write accesses to the media.

[MVV]

deleting a file is within 1..2 second.

Yes, delete doesn't take too much time. But when device is busy with read-write requests, parallel requests are much slower than when it is free. And it requires much more time to cancel copy. I repeat, we need time not to delete file, we need time to tell OS to abort copying.

[ghisler(Author)]

Please try beta 7, it will now wait for these threads to terminate - for a maximum of 30 seconds, but usually much shorter.

[MVV]

Thank you, it works excellent in beta 7!
It took about 5 seconds in my test and then TC successfully closed!

However I noticed that BTM or background copy window are visible while terminating. Maybe it is better to hide or disable them? Or maybe some other indication (like 'Terminating...' label)?

[ghisler(Author)]

What happens is that TC sends WM_SYSCOMMAND/SC_CLOSE to the background copy window, and then waits until it reacts (in a PeekMessage loop). I could hide the window with ShowWindow, or show some text in the title bar via SetWindowText - what do you think?

[MarcinW]

I could hide the window with ShowWindow, or show some text in the title bar via SetWindowText - what do you think?

It would be better to use asynchronous functions if we are expecting that the thread may hang:
ShowWindow -> ShowWindowAsync
SetWindowText -> SendMessageTimeout(Wnd,WM_SETTEXT,...)

Regards

[MVV]

I think modified window title would be good enough.

[ghisler(Author)]

OK, I will try that.

[MVV]

Looks clear with 'Transfer aborted!' in 8.50b8, thanks!

[ghisler(Author)]

Thanks!