[9.0ß3] Del key is slow to react
Moderators: Hacker, petermad, Stefan2, white
[9.0ß3] Del key is slow to react
This problem is probably the same as Delete to recycle bin behavior, but there is much more disturbing consequence, so I report it separately.
In 8.52 and earlier I've been quite used to deleting files by quickly pressing Del, then Enter (TC shows its own confirmation because my Recycle Bin is replaced by Diskeeper Undelete program). TC 9.0 either reacts more slowly to pressing Del, or it switched from synchronous execution to asynchronous, and now the Enter key is processed by TC itself instead of the confirmation dialog, which means the file under cursor is started, though user does not expect it. This is very dangerous behavior!
In 8.52 and earlier I've been quite used to deleting files by quickly pressing Del, then Enter (TC shows its own confirmation because my Recycle Bin is replaced by Diskeeper Undelete program). TC 9.0 either reacts more slowly to pressing Del, or it switched from synchronous execution to asynchronous, and now the Enter key is processed by TC itself instead of the confirmation dialog, which means the file under cursor is started, though user does not expect it. This is very dangerous behavior!
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
Flint,
Is this really new? I mean, I have confirmation before deleting non-empty dirs turned on and the recycle bin off and many times it happened (as far as I remember, I guess I am pressing keys more slowly now
) that I pressed Delete, Enter, Enter fast enough so that the second Enter is caught by the "Deleting:" dialog even before the non-empty dir confirmation shows up. So when I press Enter again to confirm, the Deleting: dialog already caught the previous (second) Enter (as if I clicked on Cancel) and I immediately got the User abort message.
What I want to say is that maybe this is not new in 9.0 (perhaps just easier to invoke).
Roman
Is this really new? I mean, I have confirmation before deleting non-empty dirs turned on and the recycle bin off and many times it happened (as far as I remember, I guess I am pressing keys more slowly now

What I want to say is that maybe this is not new in 9.0 (perhaps just easier to invoke).
Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
Your "what happened" description is exactly what I had earlier and what I expect to get, but what I no longer experience in 9.0.
See for yourself: your Delete keypress calls the "Are you sure" dialog, then your first Enter confirms that dialog with "Yes". That's the correct behavior! The Delete key caused TC to immediately block its interface and direct further input for processing by the (future) confirmation dialog. The second Enter is of no relevance here, but it's, too, processed correctly, it arrives into the expected dialog, and it's not TC's fault that you are too fast and catch it in the middle of counting/preparing progress.
Now, what I've got in 9.0: I press Delete, then Enter. Pressing Delete starts some internal initializing of the deleting action, but in the meantime TC does not stop accepting input (like it used to do), but continues to process it by the main window. So my next keypress Enter is not "hold off" until the delete confirmation dialog appears, but is sent directly into the TC main window and is processed as if I did not press any Delete. That is, is starts a file under cursor. And only after that TC finishes internal preparations and finally displays the "Are you sure" dialog. But the Enter is already processed. Now instead of what I wanted (deleted file) I have 1) an unconfirmed dialog waiting for my input, and 2) launched (possibly malware) file I wanted to delete.
See for yourself: your Delete keypress calls the "Are you sure" dialog, then your first Enter confirms that dialog with "Yes". That's the correct behavior! The Delete key caused TC to immediately block its interface and direct further input for processing by the (future) confirmation dialog. The second Enter is of no relevance here, but it's, too, processed correctly, it arrives into the expected dialog, and it's not TC's fault that you are too fast and catch it in the middle of counting/preparing progress.
Now, what I've got in 9.0: I press Delete, then Enter. Pressing Delete starts some internal initializing of the deleting action, but in the meantime TC does not stop accepting input (like it used to do), but continues to process it by the main window. So my next keypress Enter is not "hold off" until the delete confirmation dialog appears, but is sent directly into the TC main window and is processed as if I did not press any Delete. That is, is starts a file under cursor. And only after that TC finishes internal preparations and finally displays the "Are you sure" dialog. But the Enter is already processed. Now instead of what I wanted (deleted file) I have 1) an unconfirmed dialog waiting for my input, and 2) launched (possibly malware) file I wanted to delete.
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
Hacker
Then I don't understand your argument. You described a totally different result of the same action, how then my report could not be a new behavior?
Then I don't understand your argument. You described a totally different result of the same action, how then my report could not be a new behavior?
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
Flint,
I am just saying I have observed similar behavior in the past (keys being caught by other window than expected if pressed too fast), IMO my second Enter should not have been caught by the Deleting: dialog before the non-empty confirmation dialog pops up, same way as you are saying your Enter should not have been caught by the main window before the confirmation dialog pops up.
Roman
I am just saying I have observed similar behavior in the past (keys being caught by other window than expected if pressed too fast), IMO my second Enter should not have been caught by the Deleting: dialog before the non-empty confirmation dialog pops up, same way as you are saying your Enter should not have been caught by the main window before the confirmation dialog pops up.
Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
Hacker
OK, I see what you mean, but I still disagree. In your case you get the dialog — maybe an intermediate instead of final, but you get some response to your action. In my case the dialog is missing at all, and the main TC window is processing keypresses as if I did not press the Delete key at all.
OK, I see what you mean, but I still disagree. In your case you get the dialog — maybe an intermediate instead of final, but you get some response to your action. In my case the dialog is missing at all, and the main TC window is processing keypresses as if I did not press the Delete key at all.
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
- ghisler(Author)
- Site Admin
- Posts: 50549
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Well, you could choose between accurate dialog whether TC will delete directly or to recycle bin, or quick dialog, but both isn't possible.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
ghisler(Author)
What I wanted to say it's actually a regression. I don't know how it works in details, but in 8.52 I did not have this behavior, in 9.0 I have it. TC should block it's main interface until any dialog appears.
What I wanted to say it's actually a regression. I don't know how it works in details, but in 8.52 I did not have this behavior, in 9.0 I have it. TC should block it's main interface until any dialog appears.
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
- ghisler(Author)
- Site Admin
- Posts: 50549
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
As I explained, TC was waiting for the callback of the delete function which tells me exactly whether the file is going to be moved to recycle bin, or deleted permanently.
I have changed this radically now in beta 4:
1. Look in the registry whether delete to recycle bin is supported for that drive
2. If yes, show the confirmation dialog immediately
3. If the user agrees to delete, call the recycle bin delete function
4. If now the callback reports that the file would be deleted permanently, report an ERROR, abort the operation and tell the user to use Shift+F8 to delete the files.
I have changed this radically now in beta 4:
1. Look in the registry whether delete to recycle bin is supported for that drive
2. If yes, show the confirmation dialog immediately
3. If the user agrees to delete, call the recycle bin delete function
4. If now the callback reports that the file would be deleted permanently, report an ERROR, abort the operation and tell the user to use Shift+F8 to delete the files.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Thank you very much, the reported scenario works like a charm now!
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64