An adam task supports one or more commands, normally referred to as actions, (e.g. the kappa task supports ``add'', ``cadd'', ``stats'' etc.) and is instructed to execute one of them by sending it an ``OBEY'' message. The message contains the action name (e.g. ``add'') and a command line which can contain parameter values and any of the keywords that modify the behaviour of the parameter system (e.g. ``in1=test accept''). If the task recognises the action name3 it responds with an actstart message; the message name field of the message will be the action name and the status field will be DTASK__ACTSTART. The task then starts executing the command.
In the simplest possible case, where the action writes no text and does not need to prompt for any parameter values, the task completes the action and sends an endmsg message to the command language. The message name is again the action name and the status will be DTASK__ACTCOMPLETE. The task is now ready to execute another action.
If, as usually happens, the task does want to display some text, it will send one or more inform messages; the text to display will be in the value field of the message. Note that the message system makes no distinction between text and error reports, however, the adam error reporting system always prefixes the first line of an error message with two exclamation marks and subsequent lines with a single exclamation mark. If the task needs a value for a parameter it will send a paramreq message; the value field will contain the parameter name, prompt, default value etc.. The command language must reply with a paramrep message with the new parameter value in the value field.
The only other message that a task might send as a result of an ``OBEY'' is a sync message; the purpose of this message is to instruct the command language to ensure that all output has been actually written to the screen for the user to read--for example, instructions on how to perform some interaction with a graphics device. In the context of a GUI, where updates to the screen are performed asynchronously whenever the GUI process is idle, the message probably has no useful function. However, a synchrep message must be sent to acknowledge the sync message (the adamtask library described below does this automatically).
If an error occurs during the execution of a command, the status field of the final endmsg message will be the final exit status of the action; ie. something other than DTASK__ACTCOMPLETE. If the action cannot even be started (if, for example, the action name isn't recognised) there will be no actstart message and the actcomplete message will contain an error status (eg. SUBPAR__NOACT).
STARTCL --- Starlink Extensions to Tcl & Tk