F5 copy, questions asked at end - custom wait time
Moderators: Hacker, petermad, Stefan2, white
F5 copy, questions asked at end - custom wait time
About the feature: 01.09.13 Added: F5 copy, questions asked at end: If there is a dialog within the first 5 seconds, show it instead of postponing it (the user should still be there) - was 0.5 seconds in beta 1 (32/64)
Is there any chance to make this customizable? In fact, I prefer the lower or 0 wait time instead of the 5s - but this is only my preference.
Is there any chance to make this customizable? In fact, I prefer the lower or 0 wait time instead of the 5s - but this is only my preference.
"It might be a long time," said O'Brien. "You are a difficult case. But don't give up hope. Everyone is cured sooner or later. In the end we shall shoot you." - Orwell, 1984
- ghisler(Author)
- Site Admin
- Posts: 50873
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
I don't want to make this configurable because it could have unpredictable results. But I'm open to suggestions how short I should make it. 0 is not an option, because it's not catching the situation where ALL files have to be overwritten. It makes no sense to try all files and then again, you don't gain anything. To the contrary, you start the operation, TC is trying 10000 files in vain, and when you come back, nothing has been copied at all.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Thanks for the explanation.ghisler(Author) wrote:I don't want to make this configurable because it could have unpredictable results. But I'm open to suggestions how short I should make it. 0 is not an option, because it's not catching the situation where ALL files have to be overwritten. It makes no sense to try all files and then again, you don't gain anything. To the contrary, you start the operation, TC is trying 10000 files in vain, and when you come back, nothing has been copied at all.

As I wrote I prefer the lower times, but I think it is depend on the usage. That's why I suggested the customizable wait time.
"It might be a long time," said O'Brien. "You are a difficult case. But don't give up hope. Everyone is cured sooner or later. In the end we shall shoot you." - Orwell, 1984
The first suggestion would be great!MVV wrote:I think 5 seconds would be enough together with:
1. 'Postpone' button in some confirmation dialog.
2. Some indication in main operation dialog that TC has entered postpone mode.
"It might be a long time," said O'Brien. "You are a difficult case. But don't give up hope. Everyone is cured sooner or later. In the end we shall shoot you." - Orwell, 1984
Another idea (probably even better): when TC shows confirmation dialog, it waits for e.g. 1 minute and then postpones that confirmation and all the rest. So if user left PC he will see that operation is done and some confirmations are left unprocessed.
Perhaps ideal solution: show confirmations queue in a separate thread so TC can continue with operation while user answers questions, so if there are unanswered confirmations, one of them is on the screen.
However some confirmations may postpone multiple files! E.g. if 'remove read-only' confirmation is postponed, it must postpone deletion of all read-only files. And, if user answers one of them 'all', flag 'remove: all' should be set and so rest 'remove read-only' confirmations may be processed.
Of course, there are bad sides too. E.g. I see first confirmation and understand that I do bad thing.
But in case of foreground confirmations no more files will be processed... So it is better to turn postpone mode manually so user knows what he doing.
Perhaps ideal solution: show confirmations queue in a separate thread so TC can continue with operation while user answers questions, so if there are unanswered confirmations, one of them is on the screen.
However some confirmations may postpone multiple files! E.g. if 'remove read-only' confirmation is postponed, it must postpone deletion of all read-only files. And, if user answers one of them 'all', flag 'remove: all' should be set and so rest 'remove read-only' confirmations may be processed.
Of course, there are bad sides too. E.g. I see first confirmation and understand that I do bad thing.

I don't think it should not be more complex, because many people are simply lazy, so one more click will make this function unused. That's why I recommended to make it configurable via the .ini and keep the behaviour as is now.MVV wrote:Another idea (probably even better): when TC shows confirmation dialog, it waits for e.g. 1 minute and then postpones that confirmation and all the rest. So if user left PC he will see that operation is done and some confirmations are left unprocessed.
Perhaps ideal solution: show confirmations queue in a separate thread so TC can continue with operation while user answers questions, so if there are unanswered confirmations, one of them is on the screen.
However some confirmations may postpone multiple files! E.g. if 'remove read-only' confirmation is postponed, it must postpone deletion of all read-only files. And, if user answers one of them 'all', flag 'remove: all' should be set and so rest 'remove read-only' confirmations may be processed.
Of course, there are bad sides too. E.g. I see first confirmation and understand that I do bad thing.But in case of foreground confirmations no more files will be processed... So it is better to turn postpone mode manually so user knows what he doing.
I prefer 1 or 2 seconds...ghisler(Author) wrote:I don't want to make this configurable because it could have unpredictable results. But I'm open to suggestions how short I should make it. 0 is not an option, because it's not catching the situation where ALL files have to be overwritten. It makes no sense to try all files and then again, you don't gain anything. To the contrary, you start the operation, TC is trying 10000 files in vain, and when you come back, nothing has been copied at all.
"It might be a long time," said O'Brien. "You are a difficult case. But don't give up hope. Everyone is cured sooner or later. In the end we shall shoot you." - Orwell, 1984