Possible To "Queue" Commands?

[fico]

**update** just tried this again after posting and it seems to be working in the way I asked about. it wasn't a few moments ago though... I'll see how it holds up with continuous use.

So I just picked up XYplorer & it's pretty "chk-chk", I must say

I also just made my first script, which copies any selected files into an "(Archive)" folder at the current path with an added timestamp suffix. The script also "beeps" and displays a summary of the operation in the status bar ( timestamp + parent folder + files copied). Here is the script:

Code: Select all

 /* Variables */

 $strDateStamp = "<date mm-dd @ hh-nn-ss>  ";
 $strCurrentFolderName = "/ <curfolder> /  ";
 $strTargetItemNames = regexmatches("<selitems>", "[^\\]+\.\w+");
 $strModifiedItemNames = RegExReplace($strTargetItemNames, "\|", " | ");

 /* Commands */

 copyas "* [<date yyyy-mm-dd @ hh-nn-ss>].?", "<curpath>\( Archive )";
 beep 2000,50; beep 2000,100;
 status $strDateStamp $strCurrentFolderName $strModifiedItemNames, "009900", "ready";

The script works mostly fine, however, I am running into 2 small issues:
[1] The status bar summary (image A) is displayed immediately, only to be pushed aside by "all background jobs completed" (image B) when the copy operation is finished.
[2] The beep command is executed before the copy operation has completed.



Really, both of those issues have the same root cause: the commands are executed before the copy operation has completed.

Is there a way to require commands to be processed one at a time, pausing until each command is complete? Kind of in a "queue" or "stepped" (without confirmations) fashion? (I'm sure theres a proper term for that, but I'm not sure what it is... )

Also, I don't think a "wait|pause|sleep x" function would work well in this case, as copy operations can take anywhere from a few seconds to an hour or more, and I don't believe that variable can be accounted for accurately.

Ideally, this code would perform the copy operation and only beep & display the status bar summary at the moment of completion. For example, if you need to back up a few gigs of important data, and want to leave your computer in peace and bang out a few of these while you wait .

Thanks for any help!

[bdeshi]

**update** just tried this again after posting and it seems to be working in the way I asked about. it wasn't a few moments ago though... I'll see how it holds up with continuous use.

Maybe you changed something in Configuration which affects this.

All the same,
Add this code anywhere before the copyas command:

Code: Select all

 setting "BackgroundFileOps", 0;

This forces file operation to run in the foreground (only for this script though), and it sounds logical that gathering data (like when it finishes) about something in the foreground is easier than doing the same for something in in background, right?

and for the statusbar msg: add this command right after the status command:[code] wait 1; [/code]this asks XY to wait a bit. Meanwhile XY refreshes the filelist after finishing the copy, which would normally overwrite your status with the regular one. But because XY is now waiting for the script, it gives scripted status a higher priority (I think that's how it works; 1ms wait normally should not have such profound effect) and for the statusbar msg: add this command right before the status command:

Code: Select all

 wait 1000; 

this gives XY some time to upate the filelist, (and update the statusbar), and then shows your status msg. you may have to tweak the waiting period.

[edited]

[PeterH]

Hey: wait 1; waits for 1ms
(OK: in real life maybe a multiple of 10, i.e. about 10ms.)

Are you looking so fast

[bdeshi]

Okay, I did that and the status seemed to stay. I was confused, as you can gather from the post. but turns out actually I'd disabled Auto-refresh in the course of testing.
now I suggest giving XY a sec for status update.

[fico]

Add this code anywhere before the copyas command:

Code: Select all

 setting "BackgroundFileOps", 0;

This forces file operation to run in the foreground (only for this script though), and it sounds logical that gathering data (like when it finishes) about something in the foreground is easier than doing the same for something in in background, right?

The initial issue was active again today. It's odd that sometimes the beep & status bar update occurs before the copy operation starts, and then for a couple of days it would wait until the copy operation finished (with no additional settings changed in XY).

Just added BackgroundFileOps & a 100ms break before the beep. Seems to do the trick & keeps the commands executing in the right order. Good call