Redundant delete confirmation

[zer0]

I discovered the most blatant bug today: it is easily possible to create orphaned delete confirmations.

- Create a dummy text file
- Press delete but do not click on either yes/no
- Switch to a different app
- Go back into XY and press delete again but now click yes
- Minimise other windows to display the original delete confirmation and click yes
- Boom, it will obviously error out by saying that the file cannot be found since you deleted it already

Solution: either make the confirmation prompt modal or clean the orphans once the real one has been confirmed.

[admin]

Untick this and you are protected from yourself:
Configuration | File Operations | Miscellaneous | File operation progress dialog modeless

[zer0]

Untick this and you are protected from yourself:
Configuration | File Operations | Miscellaneous | File operation progress dialog modeless

That makes the dialog stick, but it does not prevent multiple dialogues from being created by a user, so there is a possibility that orphans will exist.

[admin]

How?

[zer0]

How?

By pressing "Delete" again. Unchecking that setting just causes the delete yes/no dialog to still be in your face. However, pressing Delete again generates a new dialogue on top of the original one. If you click yes on the new pop-up, then the original one is orphaned (vice versa if you do it on the first one). Clicking no on the orphan dismisses it quietly, but clicking yes pops up an error message (since you deleted the file already so it's not there to delete again).

[admin]

By pressing "Delete" again.

Not possible if the dialog is modal.

[zer0]

By pressing "Delete" again.

Not possible if the dialog is modal.

I am not known for feats of the impossible, but I have that box unchecked and I can produce this:

[admin]

Well, I can't. You have transmodal superpowers.

[TheQwerty]

[x] Enable background processing.
Apply to... [x] Delete (runs at once in parallel process)

State of File operation progress dialog modeless does not matter.

XYplorer.exe is likely unaware that XYCopy.exe is waiting on user input and has not performed the desired operation.

[admin]

OK, that way you can create that situation. But I don't think I have to do anything. Whoever ends up here should know what he has been doing and why. And even if not, nothing bad can happen. So, who cares.

[zer0]

OK, that way you can create that situation. But I don't think I have to do anything. Whoever ends up here should know what he has been doing and why. And even if not, nothing bad can happen. So, who cares.

You should care. There is no benefit to letting people generate multiple dialogues that ask the same question, so it should not be permitted. When a question's answer is either yes or no, nothing else should proceed until that question is answered. You're saying "if people want to be stupid, let them be stupid, it's not my problem".

[admin]

It's easy to create the same situation with WE. No wonder, in a multi-tasking system it's totally unsurprising that this can happen; of course, it should be handled gracefully which is done in WE as well as in XY.

Non-issue.