Red Sweater Forums

Thanks for asking - the feature is definitely "on the drawing board" and has been gradually gathering momentum for quite a while now. The fundamental complication is that it's very difficult to run multiple scripts at the same time from a single application. In fact, even applications like Script Editor that do it exhibit clunky behavior and slow responsiveness while doing so. Applications that appear to run multiple scripts simultaneously are usually running smaller "script runner" programs to do the execution invisibly to the user. Up until now, I've emphasized running scripts from the main FastScripts application, because it has always been a priority to run as quickly as possible, and I didn't want to risk slowing things down by launching a separate process for each script.

I've been thinking of switching to a mechanism by which a number of "script runners" could be running at any time. There would only be one most of the time, but if you happened to try running another script while the main one was busy, another could be launched. I think this might be a good compromise between the performance of running instantly from the FastScripts process, and the flexibility of having separate processes for each script. This infrastructure would pave the way not only for running multiple scripts, but also for improving the user experience, for instance, when a buggy script hangs forever (and requires the user to force-quit FastScripts).

As a short-term workaround, I suggest saving those time-consuming scripts as "script applications." This will cause them to open a bit slower but as they are independent applications, they will be left by FastScripts to finish on their own. For the longer term, know that I am definitely considering all of my options and hope to improve this behavior in a future release of FastScripts!

Thanks again for stopping by...

Daniel

Thanks for the vote, Nova... it's not the only thing that drives implementation priority, but it sure helps!

Yeah I've run into that shortcoming a few times, myself. I think at least running child processes would make a good option.

Is "fire and forget" feature in latest version of FastScripts? I really need this feature. Thanks

I can save few scripts as apps, but most of my scripts need to be script documents. Thanks

Hmm... maybe getting the Unix subsystem to do it? Just a random thought.

A queue might be a good idea, but then again, if the first scripts takes a long time to finish, what if the conditions that exist when the second script finally fires are no longer desirable? It's a bit tricky when doing anything other than simply firing the script right when the user wants it.

I'm not sure exactly what Boodlums is alluding to.