You can test with this script. I've only encountered this while DOpus.Dlg.detach is set to true, so may or may not happen if it's attached (not tested).
Perhaps it's caused by the way the message loop is handled in the script? If so enlighten me. It seems as if the two dialogs are on the same thread and that is why the copy dialog doesn't appear because it's looping non-stop through the script dialog?
That did the trick, thanks for sharing.
Setting to null causes the dialog not to open centered in the calling lister as well as the dialog can also go behind the lister. If I don't want that to happen it will require several more lines of code in every script that uses a detached dialog (and also attached? [not tested]). I feel that shouldn't be necessary. But I think I'd rather not suppress the Copy/Move dialog. Maybe it'll get fixed properly by the devs.
It’s working as intended, but maybe needs a way for dialogs to opt out while still being over a lister.
The aim of the default behavior is to stop asynchronous progress dialogs appearing on top of the dialog you’re working in. The operation still continues; the progress dialog just stays hidden while another dialog is open over the lister.
The thing is when you start a copy operation you kind of expect the progress dialog to appear if of course the job is big enough. Wouldn't it be better to just allow the progress dialog to appear and then the user can simply minimize it if they want? Or if the jobs bar is enabled at least let it appear there? It does make sense why the progress dialog is suppressed since the script dialog is staying on top of the lister. In my case I had dragged it off to the side of the lister which is something I do with this particular script around 15% of the time.
perhaps an option plz