Update (July 29, 2017): I describe another way of launching stand-alone scripts in a newer blog post: An Easy Way to Launch Stand-Alone Apps from Eclipse.
Launching Stand-Alone Scripts
As you may know, only plug-in scripts can be launched directly from Eclipse. Launching a stand-alone script is a bit more complicated (see the following discussion on the Varian Developers Forum: Running a standalone executable in a citrix environment).
In this blog post, I'll show you how to create a plug-in script that is able to launch any number of stand-alone scripts. Because a stand-alone script is just a program that happens to use the Eclipse API, you'll actually be able to launch any program. Tip: to avoid having to browse to the launcher script every time, you can create a keyboard shortcut to it in Eclipse (like Ctrl + L).
The working plug-in script is available on my GitHub page as AppLauncherScriptExample. I'll assume you have access to the repository as I explain the code.
Stand-Alone Script Launcher
The idea is to have a text file (which I've called scripts.csv) that holds the list of scripts to display. Each line in the file contains the name of the script, which will be displayed to the user, and the full path of the executable. The script name and path are separated by a comma. The user will be able to run a script by choosing it from a list and double-clicking on it (or by clicking on a Run button).
I've chosen to use Windows Presentation Foundation (WPF) as the framework for the user interface. The XAML file for the main view is simple. It contains a ListBox, which will display the script names, and two buttons: Run and Exit.
The ListBox is data-bound to the Scripts property in the view model. The Scripts property returns a collection of Script objects. Each Script object contains a Name property and a Path property. When a Script object is selected by the user, the SelectedScript property in the view model is set.
The MouseDoubleClick event of the ListBox is handled by a method. This method calls the RunSelectedScript method in the view model. The Click event of the Run button is handled by a method that also calls the view model's RunSelectedScript method. In other words, the selected script may be run by either double-clicking on it or by clicking on the Run button.
The RunSelectedScript method in the view model has the magic:
public void RunSelectedScript()
{
if (SelectedScript != null)
{
Process.Start(SelectedScript.Path);
}
}Process.Start simply executes the path given to it. The path doesn't actually need to be an executable file. As long as the path is associated with an executable, such as a .doc file and Microsoft Word, the correct application will start. See the documentation on Process.Start for more information.
Finally, the plug-in script may be exited by clicking on the Exit button, which obtains the Window for the current UserControl and closes it.
If you're familiar with the Model-View-ViewModel (MVVM) pattern, you may have noticed that I didn't use commands or property notifications. For this simple script, I didn't think it was necessary. Otherwise, I would have used an MVVM library, such as the MVVM Light Toolkit.
Possible Enhancements
This stand-alone script launcher can be enhanced to launch regular plug-in scripts. With such a tool, you'd be able to launch any kind of script (plug-in and stand-alone) seamlessly. I will write a blog post in the future on how to do this.
One benefit of plug-in scripts is that they get the current context of the Eclipse session. This includes objects like the patient, opened plans, and the active plan. With stand-alone scripts, you don't get any context. However, you can pass the IDs of such objects as command-line parameters and re-open them in the stand-alone app.
If you want to make the launcher even more user-friendly, you can create icons for each of your scripts and display them like a mobile app launcher.
Final Thoughts
I've thought about switching completely to stand-alone scripts (no more plug-in scripts), where the context information is obtained through the command-line. This has the advantage of running each script on a separate process, so the problems I described in Version Conflicts in ESAPI Scripts don't happen.
For example, you won't have to attach the version number of the script to its name. You'd also avoid problems related with the App.config file, where Eclipse chooses its own App.config file rather than your script's. Furthermore, multi-threading becomes a bit simpler because you won't have to use the main thread as a background thread where ESAPI operations are performed (see Create ESAPI Scripts That Don't Freeze the UI).
One disadvantage, however, is that each script would take some time to start up because the process of creating the ESAPI Application object is slow. Another disadvantage is that you would need to take the user name and password every time each script is launched, although that won't be a problem in ESAPI v. 15 because it will use the user's Windows credentials.