[8.0ß25] Switching tab while deleting - tab changed

[Flint]

0. Prepare some directory with unneeded files to be deleted, large enough so that deleting took some significant time (several seconds at least). Make sure there are no read-only, hidden or system files, so that deleting went without interruptions.
1. Start TC with clean INI.
2. In the left panel open two tabs with different paths in them. In the second tab navigate to the directory from the step 0 and set cursor on it.
3. Press Shift+Del, agree to all the confirmations, send deleting progress to the background.
4. While data are being deleted, press Ctrl+Tab to switch to the first tab, but do not release Ctrl, so that tab switch did not actually occur. Keep holding Ctrl until the background deleting finishes.
5. When deleting finishes, the path in the first tab (which is being hold by you) suddenly changes and becomes equal to that of the second tab. So does the tab title.

Tested in TC 8.0β25 x32 and x64, Win7 x64 SP1.

[ghisler(Author)]

Well, that's multitasking - I doubt that I can do much about it...

[Flint]

ghisler(Author)
Sorry, I didn't get you. Multitasking usually means running multiple tasks which do not interfere each other. But in this case a backgroung operation (the one usually sent into background and forgotten about) suddenly changed my foreground working environment. I was lucky to notice that, because the lists of files/dirs were too different. Otherwise I might end in a different directory and do some unwanted actions there, for example, delete some more files, thinking they are old backup copies, while being actually in the directory with the newest versions of my files…

[ghisler(Author)]

Well, what should I do? Halt all background threads while the user does Ctrl+Tab? I don't think that this is feasible.

[Flint]

ghisler(Author)
It's not obvious to me why a background thread should change the current tab's directory in the main TC window. I understand that it probably sends some signal so that TC refreshed the original tab contents after the operation is finished (to display the changed contents), but is it really completely impossible to prevent this action when TC is in the "tab-switching" state? Even more, TC could simply block all the re-reading signals while in this state, because they are just useless then — it might be easier to implement it that way.

[ghisler(Author)]

OK, I will try that. However, there are many other states which should be handled like this - it's just not feasible to handle them all, sorry.

[Flint]

OK, I will try that.

Thank you, that's all I ask for.

[umbra]

I can confirm that TC8 rc1 fixes this issue.

[Flint]

Fixed in 8.0rc1. Thanks very much!

[ghisler(Author)]

Thanks!