[TC 11.00b2] Copy dialog losts info-strings From: and To:

[AntonyD]

Select the big file to copy - start the copy process - you’ll see the full COPY dialog - as expected.
Note that there are information strings above the progress bar that show from where and to there & what is being copied.
Now we will put on a Pause this process AND "send" this dialog/process to the background, and then we will restore it back
into the full window (foreground) and will see.... oups, to be more precisely: we will NOT see these information strings
that have seen before(((.

[petermad]

Not confirmed - Testet with TC 11.00b2 64bit and 32bit on Windows 7 and Windows 10 and with clean ini file.

[AntonyD]

2petermad
sorry - forget to describe one more step. set on a pause the Copy process initially. Post was modified accordingly.

[petermad]

2AntonyD

forget to describe one more step. set on a pause the Copy process initially

I still cannot reproduce it - I start a copy, immediately press the Pause button, and then the Background button. In the small window I then press the Foreground button - To: and From: are show as they are supposed to.

Could you try if you can reproduce it with a fresh ini-file?

[AntonyD]

I still cannot reproduce it - I start a copy, immediately press the Pause button, and then the Background button. In the small window I then press the Foreground button - To: and From: are show as they are supposed to.

actions are correct but the main bottleneck is in.....
Maximized state of Total window itself! And yes all actions were made with a fresh INI.
I just always have this working state of the TC window. And I always expand it automatically, even if it's a launch with a fresh INI.
I just decided not to do it now))) and found that it's a correct decision))

Also imho I found another problem. IF I put copy process on a pause, set the dlg !only! in background - I DO NOT assume that the process in background should silently restart/continue the copy process! And right now i see exactly that case! So I MUST reopen this background dlg and AGAIN put the copy process on a pause.... And the same when I revert it from background into foreground - I DO NOT assume that copy process should immediately start/continue again! For all such cases related buttons exist on a form - Start/Pause! I will use them! In case If i want to activate this Copy process in anyway.

[ghisler(Author)]

I cannot reproduce that even when Total Commander is maximized. There must be some additional condition.

Also imho I found another problem. IF I put copy process on a pause, set the dlg !only! in background - I DO NOT assume that the process in background should silently restart/continue the copy process!

Unfortunately move to background only works while the process is active, not while it is paused.

[AntonyD]

Unfortunately move to background only works while the process is active, not while it is paused.

And how does this fact stop us from having the process sent to the background from the state of "pause" temporarily activated, and then put again "on pause" - because there the user did so initially? And the same thing when we bring the process out of the background. Temporarily activated, moved to the foreground and paused again - because the user did so.

[AntonyD]

There must be some additional condition.

I can't find anything else. I launch a freshly installed copy of Total with a fresh INI file.
Repeatability 100%

P.S.
Oh jeez...
This problem is only for the 64 bit version. 32 bit works as it should.
Again, these reasons are obviously in different compilers and outdated libraries.

[ghisler(Author)]

Just tried with a fresh ini, doesn't happen also with 64-bit.
Maybe it's a language file problem? Could you try with English?

[AntonyD]

Fresh INI already uses exactly and only English So let's assume that I already follow you suggestions)))
https://ibb.co/y6kvZyH

[AntonyD]

Maybe a freshly launched Total reads something from the registry? Indeed, with such a start, which it is not a portable state, it tries to write and read something necessary in the registry, as far as I understand. And there, somewhere, some records from previous launches could remain.

[petermad]

I tried with TC maximized, making i necessary to pres Alt+Tab to get the background copy window in front, but I still cannot reproduce the problem.

[AntonyD]

Well, because this problem is really not declared by a large number of users - it means that its repeatability conditions are tied to my laptop. So you can not consider this bug significant.

P.S. for the last attempt to check the reproducibility - switch to the background window only with the mouse - without the keyboard. And first, pause the process, which automatically restarts after transferring it to the background. And all with just a mouse.

P.P.S.
And you can also select a veeeeeeeeeeeeery large file and "put" it into the background and back several times FOR one attempt of copy process!!! - every time with a stop for a pause - as before "put" it into the background so and before "get it back" into the foreground! This clearly should increase the chances of repeatability, because it seems to me that this is precisely the essence of the problem.

[petermad]

switch to the background window only with the mouse

I tried that by clicking on TC's background copy button in the Taskbar. I tried with a 11 GB zip file. and switched between background an foreground copying many times each time pressing Pause first in the Foreground copy dialog before putting it to the background, and sometimes pressing Pause in the background copy dialog before putting it to the foreground. Could not reproduce the problem.

I tried the same with a fresh ini - still no problems.

Then I went to Windows 10 with a fresh ini file, maximized TC window and switching window via the taskbar (mouse) - now I managed to reproduce the problem, but it was when I at the second switch from foreground to background copying did NOT press Pause before pressing Background, and with no pressing Pause in the background copy dialog.

I could not reproduce it with my usual .ini file on windows 10, but I have disabled "Standard copy method" and use big file copy method here.

If I start TC with a fresh ini and disable "Standard copy method" and use big file copy method - I can no longer reproduce the problem.

I could never reproduce it under Window 7.

It seems easier to reproduce the problem if I copy from a WiFi connected Network Share.

My Windows 10 computer is very slow, so whether it is because of that or because it runs Windows 10, I don't know.

[petermad]

It is not mentioned in history.txt, but this seems to be fixed in TC 11.00b3