Restricting an Action Based on the Number of Arguments

Use the ARG_COUNT field to specify the number of arguments the action can accept. Valid values are:

* (Default)--any number of arguments. Other values have precedence over *.

n--any non-negative integer, including 0.

>n--more than n arguments.

<n--fewer than n arguments.

One use for ARG_COUNT is to provide different action icon behavior, depending on whether the user double-clicks the icon or drops a file on it. See the next section, "To Provide Different Double-Click and Drop Behavior."

To Provide Different Double-Click and Drop Behavior

Use this procedure to create an action that accepts a dropped file but does not prompt for a file when the action icon is double-clicked.

1. Create an action definition for the double-click functionality.

   Use the ARG_COUNT field to specify 0 arguments. Use a syntax for the EXEC_STRING that does not accept a dropped argument.

2. Create a second action definition for the drop functionality.

   Use the ARG_COUNT field to specify >0 argument. Use a syntax for the EXEC_STRING that accepts a dropped file.

   For example, suppose the following two command lines can be used to start an editor named vedit:

   • To start the editor with no file argument:

     vedit

   • To start the editor with a file argument that is opened as a read-only document:

     vedit -R filename

     The following two actions create drop and double-click functionality for an action named Vedit. The first action has precedence when the database is searched for a match, since ARG_COUNT 0 is more specific than the implied ARG_COUNT * of the drop functionality definition.

     # Double-click functionality ACTION Vedit { TYPE COMMAND ARG_COUNT 0 WINDOW_TYPE PERM_TERMINAL EXEC_STRING vedit } # Drop functionality ACTION Vedit { TYPE COMMAND WINDOW_TYPE PERM_TERMINAL EXEC_STRING vedit -R %Arg_1% }

Restricting an Action Based on the Mode of the Argument

Use the ARG_MODE field to specify the read/write mode of the argument. Valid values are:

* (Default)--any mode

!w--non-writable

w--writable

Creating Actions that Run Applications on Remote Systems

When discussing actions and remote execution, there are two terms that are used frequently:

database host--the system containing the action definition

execution host--the system where the executable runs

In most situations, actions and their applications are located on the same system; since the default execution host for an action is the database host, no special syntax is required.

However, when the execution host is different from the database host, the action definition must specify where the execution string should be run.

The ability to locate actions and applications on different systems is part of the client/server architecture of the desktop. For a more in-depth discussion of networked applications, see "Administering Application Services".

Creating an Action that Runs a Remote Application

Use the EXEC_HOST field in the action definition to specify the location of the application.

Valid values for EXEC_HOST are:

%DatabaseHost%--the host where the action is defined.

%LocalHost%--the host where the action is invoked (the session server).

%DisplayHost%--the host running the X server (not allowed for X terminals).

%SessionHost%--the host where the controlling Login Manager is running.

hostname--the named host. Use this value for environments in which the action should always be invoked on one particular host.

%"prompt"%--prompts the user for the host name each time the action is invoked.

The default value is %DatabaseHost%, %LocalHost%. Thus, when the EXEC_HOST field is omitted, the action first attempts to run the command on the host containing the action definition. If this fails, the action attempts to run the command on the session server.

Examples

• This field specifies host ddsyd:

  EXEC_HOST ddsyd

• The field prompts for a host name:

  EXEC_HOST %"Host containing application:"%

• This field specifies that the action will attempt to run the application on the host containing the action definition. If this fails, the action will attempt to run the application on host ddsyd.

  EXEC_HOST %DatabaseHost%, ddsyd