Deleting/Recycling: Run async in background

Hi, awesome people :slight_smile:

I have a routine that should run every time something relevant changes in my lister tabs.
I wrote a script that handles OnAfterFolderChange, OnOpenTab and OnCloseTab, calling a function like this:

function startTheThing(){
    var cmd = DOpus.Create().Command;
    cmd.AddLine("@async:dopusrt /cmd MyInternalCommand");

and a separate script for the internal command which is essentially a background task handling TabGroup backups, using internal commands DELETE, RENAME and GO TABGROUPSAVE.
Flavor/Details: Since I want to save tab groups, I guess I need to use internal commands.
Because this runs every time I navigate in my lister, and it isn't instrumental to the navigation itself, it should run asynchronously, so it won't slow down my browsing. (I'm expanding this routine to shuffle around backups. Before, I only had one .otg file which I always just overwrote; that was simple enough to run synchronously)

Every time the command is called, the lister window loses focus for about half a second.
I'm trying to prevent anything happening in the foreground by using @runmode:hide. When that didn't work, I thought "maybe it's switching focus to a progress window I can't see because it disappears too quickly", so I added @noprogress, but still no luck.

A) Can I change something about the calling function to prevent losing focus?
B) Is there a better way to run a script function asynchronously, without using dopusrt? (That approach was what cropped up when I googled)

Thank you for your time and patience!

It depends on what the command being run does.

Upon closer inspection, it turns out that the focus loss happens even when I'm not using dopusrt or async.
Can somebody verify this? Here's a script file that should illustrate it. (2.6 KB)
You should be able to go to "/dopusdata\TabGroups" and hit refresh a bunch of times to see the backups created.

Ooookay, after a bunch of testing and trial/error, it seems that the focus loss happens whenever something has to be deleted. Both when deleting the oldest backup manually using DELETE or when overwriting it automatically with the RENAME ... WHENEXISTS=delete command.
What might cause this?

The Windows Recycle Bin steals the focus momentarily (probably for its progress dialog, even when it creates it but never makes it visible).

There isn't any way around it (that is documented or that we've been able to find, at least).

If you change the delete command to bypass the Recycle Bin (NORECYCLE) then that won't happen, since Opus itself handles the deletion, but then the deletion cannot be undone, of course.

Wow, that is indeed it!
I tried removing the "RECYCLE" argument at some point, not realizing that that was the default (so the opposite had to be specified explicitly) and when it didn't change the behavior, I dismissed the idea.
For my use case, I really don't need the recycle option anyway, so I'm happy with just dropping it (I just like to keep things non.destructive in general, so that's why I added it in the beginning)

Now I'm curious... Could there be a hacky way to achieve this?
If the drive in question supports recycling, movie the file to a temporary DOpus recycle folder immediately, if necessary and possible, and then taking your time in the background to rename/move it to the $RECYCLE.BIN/RECYCLER folder and adding an entry to where ever the name table is stored?
Not sure where that last part would be, I've never come across it "in the wild", but from the looks of it there should be a database or registry, assigning hash-y(?) temporary filenames to entries containing the original filenames and attributes, right?

In any case, I'm once again very thankful and so happy to see how active and helpful you guys in general, and you, Leo, in particular are. You're doing a great service to productivity and user empowerment with DOpus anyway, and then there's helpful and speedy support.
I love to see that <3 :slight_smile: