[9.21a] Buttons in overwrite file dialog are inaccessible

[veatroub]

Prerequisites: files "file1", "file2", "file3" are on source panel and file "file2" is on target panel. File "file1" should be big enough for copying to take it at least for a few seconds.
Steps to reproduce:

1. Select files "file1", "file2" and copy or move them to target panel using queue or background copying/moving.
2. During the copying or moving of "file1" drag "file3" to target panel and don't drop it.
3. Wait until overwrite file dialog for "file2" appears.

Expected result: buttons in overwrite file dialog can be pressed with mouse clicks.
Actual result: mouse clicks cannot be used for pressing buttons, only keyboard buttons can be used for intaractions with this dialog.

[ghisler(Author)]

Unfortunately this looks like a bug in Windows itself. I don't think I can do anything about it.

[MVV]

Maybe I'm doing it wrong, but I can press dialog buttons.
I start copying of two files, press F2 for BTM or OK and Background, then start dragging third file, and when confirmation appears, I simply release mouse button and click dialog buttons (but after releasing mouse cursor over the main TC window looks like dragging is still in process, and left clicking selects/deselects files).

[ghisler(Author)]

I can reproduce it with TC 64-bit, but not with TC 32-bit. So maybe there is a way to prevent it also in 64-bit...

[ghisler(Author)]

I found a solution for TC 9.22 RC2, please test it!
1. When the left or right mouse button is down, TC now waits 5 seconds.
2. If it is still down, it sends ESC to the main window, and then shows the overwrite dialog.

[veatroub]

I've installed 9.22 RC2 and it looks like it works differently that you've described.
As I can see new version waits until mouse is released in drag & drop operation and then shows overwrite dialog. I'd been waiting for 30 seconds after progress bar in Windows' task bar stopped moving, and d&d operation hasn't been cancelled by TC. I'm pretty sure that copying of first file were finished, because first file is like 100 megabytes and second is like few kilobytes, and the progress bar stuck approximately at 99%.
In 1-2 seconds after dropping file overwrite dialog appears and it works as it should work, but if I quick enough to drag third file again before dialog appears I can still reproduce this bug.

[ghisler(Author)]

1. Does your Windows have an uptime of > 25 days?
2. TC waits one second after aborting the drag to ensure that even slow PCs have the time to properly abort it. I think that the user should be clever enough to notice that the drag was aborted. But I can send a second ESC afterwards if needed.

[veatroub]

1. No, I've done these tests just a few hours after starting my PC.
2. I don't see d&d operation aborting by TC. TC waits until I finish it. Overwrite dialog appears only after I release mouse to drop the file.

[ghisler(Author)]

That's strange, I re-checked my code, and it only waits for 5 seconds while the mouse is down, then it forcefully aborts the operation.

Which Windows version do you use?
Do you use remote access (e.g. Terminal Services), or local access on that PC?

[veatroub]

It is Windows 7 SP1 x64 that are loaded directly from HDD without any remote access.