DO12 - Confirm replace - skip - window cycle bug(?)

I noticed some unexpected behavior concerning opus windows popping up randomly and managed to narrow it down to the confirmation dialog for file operations.

Here are the steps I used to reproduce it:
[li]Open 3 listers on 3 different displays.[/li]
[li]Main lister can be maximized, the other two should be normal window state but visible (not minimized).[/li]
[li]In the main lister start moving many files from one folder on the left pane to another on the right (same drive) - make sure there are duplicates.[/li]
[li]When a "file already exists" is triggered multiple times in a row - hitting skip sometimes briefly activates the other listers before switching to the MAIN one. Doing so it also cycles their global window Z order - either putting them behind other open windows from other processes or bringing them to the foreground.[/li][/ul]
It could be that the other listers reshuffle their position in the system window list when one of them loses focus but that's hardly expected behavior and is as annoying as those listers keep coming to the foreground and then going back.

The same thing might happen with other operations as well so it could not be exclusively related to "skip".

Some additional setup info:
Dopus 12.3.1 x64 Windows 10 x64 (1607)
The other two listers are NOT on the same folders and have NO tabs with the folders in which I'm doing operations.

Did this also happen with 12.3 or is it new with the 12.3.1 beta?

12.3.1 has a change to fix a related z-order issue which could be involved and creating a new issue. But if you saw it in earlier versions then we can broaden our scope of where to look for the cause.

Unfortunately I only found it out today so I'm not really sure if it was in the last beta. I don't merge folders so often but I can't rule out the possibility.

I do remember seeing something like that in the past occasionally, but I can't exactly put my thumb on it or if it was as common.
IIRC there was a somewhat similar peculiarity that occurred from time to time when getting a confirmation dialog for shift+delete, dopus would focus the dialog box and immediately change focus to something else - so sending "return" to complete the combo would not work on the default button as it was supposed to.

We think we have a fix for this in the next beta. Please let us know if it still causes problems, of course!

I managed to test the new beta and I can no longer reproduce the above problem :slight_smile:
However when clicking on skip while queuing multiple move operations - an empty inline progressbar appears and when it does - after finishing the move process Dopus loses focus in favor of the last active application other than itself.

To reproduce:
[li]Start by moving 10 files (which exist in the destination).[/li]
[li]Skip first 5.[/li]
[li]Start moving the same 10 files again thus queuing the next operation - hit ok for queue.[/li]
[li]We get an inline progressbar and Dopus loses focus (<- it should not).[/li]
[li]Click minimized progress bar to restore it.[/li]
[li]Skip all remaining files.[/li]
[li]At the end another application is focused and not the lister (<- wrong again).[/li][/ul]

Delayed progrss indicators and Minimize progress indicators is checked in Preferences.

I did some further observation on this topic. Here's another misbehavior:

[li]Attempt to inline rename one file and make it's name the same as an already existing one.[/li]
[li]Error occurred renaming...[/li]
[li]Hit ESC to cancel rename and dismiss dialog. => Another lister gets focus even if that lister is minimized[/li][/ul]

It's probably not worth doing more tests on this with the current beta, as they'll be invalidated (and hopefully all fixed!) when the next beta is out.

If you still see any problems in the next beta then we definitely want to know about those, of course.