Table of Contents
While it is quite easy to open display or other CSS configuration files inside CSS, i.e. when CSS is already running, there is often also the need to open such files from outside of CSS. This is especially important for sites that are transitioning to CSS. If legacy control system tools can somehow open CSS displays from the command line, i.e. also from within shell scripts, the transition can be much smoother.
The Eclipse Launcher supports a command-line option
--launcher.openFile some_file_name.ext
When this option is found, the launcher will send the
SWT.OpenDocuments event to the RCP application.
The launcher will also check for another copy of the RCP application.
If it detects that another copy of the RCP application is already
running, it will send the event to that application.
Fundamentally, this accomplishes the goal: CSS can receive the names of files that it should open from the command line. Duplicate instances of CSS are automatically prevented.
To benefit from this Eclipse feature, several steps are necessary.
The launcher needs to detect another instance of CSS that might already be running, and it has to be able to do this on all supported operating systems. Eclipse depends on the following correlation between the product name and the launcher name:
css.
You configure the launcher name in the “Launching”
tab of the editor for your *.product file.
On Windows, the resulting launcher is actually called
css.exe.
*.product file,
in the “General Information” section.
After pressing the “Synchronize” link on the Overview tab
of the product editor, you should find the same application name
in the product's plugin.xml file like this:
<extension id="product"
point="org.eclipse.core.runtime.products">
<product
application="org.csstudio.your-site.product.application"
name="Css">
<property name="appName" value="Css">
</property>
...
The key here is that the appName matches the
name of your launcher with the first letter capitalized.
Your CSS application needs to handle the received
SWT.OpenDocuments events.
When you use the Workbench class
from the plugin org.csstudio.utility.product,
its ApplicationWorkbenchAdvisor will attempt
to open all received files.
To accomplish this, it relies on the DisplayUtil from the
org.csstudio.openfile plugin.
The org.csstudio.openfile plugin declares
an extension point org.csstudio.openfile.openDisplay
that other plugins can implement to support opening their
files from the command-line.
One example is BOY, which will open *.opi
files in the BOY runtime.
One might think that the existing Eclipse registry entries for
editors are sufficient to associate file types with a handler that
can open them. The editor registry, however, allows for the registration
of multiple editors. When using that to open files from the command line,
it would be hard to predict if for example an *.opi file
was opened in the desired BOY runtime, or in the BOY editor, a generic XML
file editor or a plain text file editor.
The designated ...openDisplay extension point avoids such
ambiguities.
As described so far, a CSS product can open files from the command line when called like this:
css --launcher.openFile some_file.opi
When adding the following to the *.ini
file of your product, simply listing the file name is sufficient:
--launcher.defaultAction openFile
Note that this is the *.ini file of the product,
not the configuration/config.ini.
If the product is called css, that file is in the same directory
as the launcher and called css.ini.
Instead of manually editing the file, add the --launcher.defaultAction openFile
in the *.product file under
“Launching Arguments”,
“Program Arguments”.
For one, this can be more convenient. In addition, this is necessary
to support opening files on windows when you double click a file
that is associated with CSS, or you select files and choose
“Open With” or “Sent To” CSS,
because that mechanism will invoke CSS with just the file names,
lacking the --launcher.openFile option.