Table of Contents

JobRunner - Control & User Interface

<Job>

The overall document tag.Attributes:

<Parameters>

Starts a block of <Parameter> child tags. Parameter values are stored as global variables. Note that a <Parameters> block does not execute children other than <Parameter> and <ParametersCancel>. The global variables created are available to all subsequently executed tags regardless of nesting.

If you want access to a parameter label later in the job, eg in an error message, use a variable to hold the label.

Example

<Parameter>

Each parameter within a <Parameter> parent tag. The tag text is the descriptive prompt. If missing the name attribute is used. Attributes

See Publishing Web Services for information about retrieving http parameters and headers when publish a web service.

<ParametersCancel>

If one of these appears as a child of a <Parameters> tag it will be executed if Cancel is pressed. If not, pressing Cancel causes the job to be cancelled.

<SetVariableBlob>

Sets a variable to a Base64 encoded blob. Gets the blob from the blobstore or a file. Sets LastSetVariableBlobSize to the non-encoded size. Use either blobid and blobclass OR filename for the source. Attributes

<SetVariable>

Sets the value of a variable from either a SQL expression or a string or arithmetic on x1, x2 and operator or by one or more <Write…> commands. If no variable of the specified name exists a global variable is created. x1, x2 perform integer arithmetic only. If you need to do float arithmetic or date manipulation use a SQL expression. If you just need string concatenation use the Value attribute with {} substitutions. If neither sql nor value nor x1,x2 attributes are supplied, tag text will be looked for and an export will be opened into which the variable contents can be ‘written’ by descendents. Attributes

Using SetVariable to interact with Woodpecker forms

SetVariable can be used to set values on a Woodpecker view. The name attribute is used to indicate the required field eg:

<SetVariable name="WPK_Q_Postcode" value="{PostCode}"/>

If the field is not on the master query of a form, the view name should be specified eg:

<SetVariable name="WPK_Q_ViewID.ItemID" value="whatever"/>

WPK Form switch values can also be set in this way eg:

<SetVariable name="WPK_F_SwitchName" value="whatever"/>

<If>

Tag children only executed if the comparison evaluates to True. Unlike IfSQL If does not use the database engine to perform the comparison. Attributes

Examples

<IfSQL>

Tag children only executed if the SQL condition evaluates to True. Attributes

<IfFileExists>

Tag children only executed if the specified file exists. Attributes:

<IfFileDoesNotExist>

Tag children only executed if the specified file does not exist. Attributes:

<IfFileReadOnly>

Tag children only executed if the specified file has the Read Only attribute set. Attributes:

<IfAnyRows>

Tag children only executed if the nearest ancestor Query has remaining rows.

<IfNoRows>

Tag children only executed if the nearest ancestor Query has NO remaining rows.

<ForEachRow>

Tag children executed for each remaining row in the nearest ancestor Query.

If there are no rows returned by the ancestor Query, then the tag children are NOT executed. It is not necessary therefore to wrap <ForEachRow> tags in an <IfAnyRows> tag UNLESS some other activity is required before or after the <ForEachRow> children are executed.

<NextRow>

Forces query to move to the next row. E.g. to ignore the first row or alternate rows.

<IfOKDialog>

An Ok/Cancel dialog. Tag children only executed if Ok clicked. Attributes:

<IfCancelDialog>

An Ok/Cancel dialog. Tag children only executed if Cancel clicked. Attributes:

<IfYesDialog>

A Yes/No dialog. Tag children only executed if Yes clicked. Attributes:

<IfNoDialog>

As above but tag children only executed if No clicked. Attributes:

<Else>

Tag children only executed if preceding <If…> tag evaluated false. Must be sibling not child of the If… tag. Some other tags like <ExportFile> execute an <Else> if the cancel button is pressed. Some like <HTTPRequest> do so on failure.

<MessageDialog>

An Ok dialog. Attributes:

Example

<Message>

Updates the message on the background of the window using the tag text or the text attribute. If the messagelogfile attribute has been specified in an ancestor tag the text will also be appended to the specified file, prefixed by date and time see Logging. Attributes:

Sometimes the message text is not updated immediately, especially if the next command is long running eg a query. In such cases it can be helpful to follow the <Message> command with a <Wait> command with a very short interval eg <Wait seconds=“0.1”/>

<Title>

Updates the job title. This appears on window and dialog titles. Attributes:

<Finish>

Immediate termination of job. If text attribute not specified final background message will say ‘Finished’. Attributes:

<Cancel>

Like <Finish> but final background message reads ‘Cancelled’ instead of ‘Finished’.

<Loop>

Keep executing child tags until a <Break> tag is encountered.

<Break>

Break out of the nearest enclosing <Loop>. If not in a loop behaves like <Finish>.

<Block>

Normally an exception will cause the Job to terminate with a message. If you wish to handle exceptions place the protected code as descendants of a <Block> and the exception will just terminate the block (and execute the immediately following <Catch> if there is one).

<Catch>

Exception handling code. Should be the next sibling of a <Block>. The exception text is available in the Exception pseudo-field.

<Throw>

Allows you to generate an exception. Attributes

<Local>

Allows the declaration and initialisation of local variables, as attributes of the tag. Descendant tags have access to these variables, and they hide any variables of the same name with external or global scope. Attributes of Local tags are accessed WITHOUT the usual $ prefix, and formatting attributes may NOT be set as attributes of a Local tag. Attributes: The local variables and their initial values.

Example

<Call>

Call a sub-routine. The tag text is the name of the routine – which should be a tag within /Job/Library. Attributes of Call are available as local variables within the called routine WITHOUT the usual $ prefix, and formatting attributes may NOT be set as attributes of a Call tag. The attributes of the CALLED tag are not used, but may be set with explanatory comments in the values, as a convenient way of documenting the routine. To pass values out of the routine use global variables or variables with a scope external to the routine (see Local). If temporary variables are used within the routine it is highly desirable to use a Local block to prevent unintentionally over-writing external variables.

Sub-routines may be in external files. Place <Include>filename.xml</Include> in /Job/Library. The procedures should be placed within /Job/Library of the included file. See example under <Include>.

Attributes The sub-routine arguments and their values.

New feature: instead of placing the procedure name in the tag text you can use a procedure or proc attribute to make it more readable.

<Library>

Container for sub-routines. Each the code for each sub-routine is contained in a tag with the name of the sub-routine within the Library tag. Sub-routines can reference each other. See Call for details of how to call Library sub-routines.

<Include>

Library sub-routines can be held in an external file. Place <Include>filename.xml</Include> in /Job/Library. The procedures should be placed within /Job/Library tag of the included file.

Example

<OpenForm>

Open an application form of the given id. Static forms are hard coded in the application, non-static forms are defined in Woodpecker. If a # version of the form exists that will be opened in preference. A single form switch can be passed as the tag text. Multiple form switches require a succession of Writeln tags. Attributes

Note that static forms will not open if another instance with the same formid already exists.

To open an internal browser window that loads pages from the LocalWebPage table use formid INTERNALBROWSER. First parameter is the URL and the second is the form id, followed by the required window title, separated by a dollar symbol.

Example

<CloseForm>

Close a Woodpecker form. Attributes

<Wait>

A timed delay for external processing. Attributes:

<PersistFields>

Saves the current row field values of the immediate parent query as variables of the same names. This means that they persist after the query is closed. This may simplify some jobs by reducing nesting. Note that variables are appended to the end of the field stack unlike fields and locals which are 'pushed' and 'popped' i.e. inserted at the beginning of the field stack and removed again on close of the query or local block. This behaviour can be observed in the debugger. Note that it will usually replace global variables but if you have local variables or library procedure arguments of the same name you may not get what you expect. Use sparingly and with caution.

Back to Technical Help Section list
Back to JobRunner user guide