top of page

Why I Don't Use the Eclipse Script Wizard

The Eclipse Script Wizard is a program that allows you to easily create single-file plug-ins, binary plug-ins, and stand-alone apps based on ESAPI. (For tips on when to use each type of script, see my blog post Single-File Plug-In vs. Binary Plug-In vs. Stand-Alone App). The wizard comes with your ESAPI installation, and the ESAPI Reference Guide explains how to use it.


Although it's fine for getting started with ESAPI, I don't recommend using the wizard for "real" scripts. The main reasons are that it doesn't organize your files properly and it doesn't create Visual Studio solutions—it only creates projects.


Bad File Organization


For a single-file plug-in, the wizard puts the C# file into a shared Plugins directory (a.k.a. folder). This means that all single-file plug-ins created by the wizard are thrown into the same directory.


This file organization is terrible for version control. You're forced to using a single repository for all your scripts. This is a bad idea because your commit history will contain commits from different scripts. Not only is this confusing to you and to others working on different scripts, but managing the history for any one script will be a nightmare.


For binary plug-ins, the wizard does a similar thing: it puts the binary files (the DLLs) into the same Plugins directory as the single-file plug-ins. The source files are in their own directory at least, so you're able to have separate version control repositories for each binary plug-in.


The only benefit with putting everything into one directory is that you won't have to browse your file system to find the script in the Eclipse launcher. Of course, it would be even better to have a smarter script launcher that allows you to keep your scripts in their own directories yet doesn't make you hunt for them.


No Solutions


For any script type—single-file plug-in, binary plug-in, or stand-alone app—the script wizard does not create a Visual Studio solution. It only creates a project.


However, projects are incomplete without a solution. In fact, when you create a new Visual Studio project you're actually creating a solution with one project. If you try to save a project by itself, Visual Studio asks you to create a solution for it.


Creating Scripts Manually


For the reasons above, I prefer to create script projects in Visual Studio manually. The ESAPI Reference Guide has instructions on how to manually create each script type. I'll summarize those steps here.


To create a single-file plug-in script, open Visual Studio and go to File → New → Project. Choose "Class Library" and name the project (and optionally, the solution). Add references to PresentationFramework, PresentationCore, WindowsBase, and System.Xaml. Also add references to the ESAPI libraries: VMS.TPS.Common.Model.API and VMS.TPS.Common.Model.Types, located at C:\Program Files (x86)\Varian\Vision\13.6\Bin64\esapi\. Change the project "Platform target" to "x64". Rename the main C# file to the name of your script and replace the contents of the file with the following:


using System.Windows;
using VMS.TPS.Common.Model.API;

namespace VMS.TPS
{
    public class Script
    {
        public void Execute(ScriptContext context, Window window)
        {
            // Your code here.
        }
    }
}

(If you're not going to use the Window, you can leave out that parameter.)


To create a binary plug-in script, follow the same steps as single file plug-in. (This is a benefit of creating your own solutions: it's easy to turn a single file plug-in into a binary plug-in.) Then, open the project's properties and go to the Application section; add ".esapi" to the Assembly name. I recommend that you use EclipsePlugInRunner to test your scripts (see my blog post Run and Test Plug-In Scripts from Visual Studio).


To create a stand-alone app, create an executable project (like WPF or Console) and reference the ESAPI libraries. At some point in your program you'll need to create the ESAPI Application object, which you can use to open (and close) patients:


using (var app = Application.CreateApplication(null, null))
{
    var patient = app.OpenPatientById("1234567890");

    // Your code here.

    patient.ClosePatient();
}

Stand-alone apps can be launched like a regular program, but this may be difficult if you're behind a Citrix system. For a solution, see my blog post Launch Stand-Alone Apps from Eclipse.

Related Posts

See All

ESAPI Essentials 1.1 and 2.0

A few months ago, I introduced ESAPI Essentials—a toolkit for working with ESAPI (available via NuGet). I've recently added one major feature: asynchronous access to ESAPI for binary plugin scripts. Y

Announcement: ESAPI Subreddit

A few months ago, Matt Schmidt started the ESAPI subreddit. It's another useful resource for finding and discussing ESAPI-related topics. According to the description, This community is to post and di

Dump All Patient Data from ESAPI

If, for whatever reason, you need to dump out all of the data for a patient from ESAPI, there's a quick and dirty way to do it. Well, there are probably several ways to do it, but here's one I've foun

Comments


bottom of page