Bypass XYplorer's Being Busy When Running Scripts

[Enternal]

One problem with XYplorer is that when it's running a script, it can't really do anything else. Due to certain scripts that I run, I can't minimize, maximize, or do much with XYplorer because it's busy processing the script. One good example is 40k's Youtube script which when using XYplorer's built in download feature, you can't minimize XYplorer. So this might be useful for some people.

The one way you can deal with this issue is launch another instance of XYplorer using:

Code: Select all

Run """<xypath>\<xyexe>"" /ini=""<xyini>"" /win=min /script=""Script""";

<xypath>\<xyexe> is obviously the path to XYplorer.exe. /ini=""<xyini>"" forces XYplorer to launch a new instance regardless of the "Allow Multiple Instances" setting under "Startup & Exit" in the settings. /win=min forces the new instance to be launched minimized so that it won't get in the way of your current instance of XYplorer. Finally /script=""Script"" runs the selected script. So basically you run pre-run Program.xys that launches a new instance that process your main code ProgramMain.xys that does the actual thing that you want it to do. After your main program finish running, you can then use:

Code: Select all

Exit "n";

To exit that instance without saving that session.

One issue is that variables do not carry over even if you have "Remember permanent variables" on because you must save your current session before it is registered in the new instance. If somehow you need to save variables in your pre-run program, you can bypass by using something like:

Code: Select all

WriteFile("<xyscripts>Variable.txt","$Variable",,t);

and then use:

Code: Select all

$Variable = ReadFile("<xyscripts>\Variable.txt",t);

in your main script.

So in the case of the Youtube scrip, the pre-run script would launch a new instance of XYplorer that run the main script, download the Youtube video, and then quit once it finish downloading. That new instance is already minimize so you can do whatever you were doing before with XYplorer or the desktop.

The whole working method is found here in my new script:
http://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=9472

The pre-run program is LongPathFinder.xys which opens a new instance of XYplorer and run the main program which is LongPathRun.xys.

Have fun!

[40k]

The issue I see here is that variables are not carried over. I'm not a big fan of writing swap files to disks since it introduces one more point of failure usually related to read/write access restrictions. It would be awesome if one instance of Xyplorer could access the memory space from another instance and read data straight from there.

[Enternal]

The issue I see here is that variables are not carried over. I'm not a big fan of writing swap files to disks since it introduces one more point of failure usually related to read/write access restrictions. It would be awesome if one instance of Xyplorer could access the memory space from another instance and read data straight from there.

Hehe yeah I prefer not to do that either. However you don't really need to do that in this case. You can just rely on:

Code: Select all

Run """<xypath>\<xyexe>"" /ini=""<xyini>"" /win=min /script=""Script""";

to run the second script that does everything else. Of course that does not fit all scenarios like in my case where I needed to know what the selected files were...

[Marco]

The issue I see here is that variables are not carried over. I'm not a big fan of writing swap files to disks since it introduces one more point of failure usually related to read/write access restrictions. It would be awesome if one instance of Xyplorer could access the memory space from another instance and read data straight from there.

You could "inject" variables using the messenger below. Maybe tweaking the part that recognizes the XY secondary window.
I guess that if the second instance of XY has a special title [see page 107 of pdf help] like

Code: Select all

[SCRIPTING INSTANCE] - blah blah blah

the you should be able to find it via AutoIt imposing a condition both on window class and window title...
But I'm not an AutoIt guru so don't count on me