Register usage conventions

There are many places in Match-IT where a script can be invoked from a form or list to perform some function, for example on the list of customers there are ‘Add’ and ‘Edit’ buttons (when the user interface level is high enough) that can be attached to a script. In such cases information from the form or list is passed to the script in registers (see accessing registers). In addition a special default (drTemplateParam) is set to a value that represents the operation to be performed.

There is also a mechanism to 'hook' almost all events for almost all controls for almost all windows within the UI (User Interface). This mechanism allows an expression to be attached to an event that is evaluated whenever that event is triggered. This is useful to override, or augment, the standard behaviour within a window for a particular control. These 'hook' expressions are passed context information in registers.

Scripts can also be invoked from your methods to evaluate method elements (e.g. what material to use, dimensions, etc.). This context is referred to as PPS (Parametric Product Structures).

In all cases the scripts are expected to return a single result that is appropriate to the context. The scripts return a result using the return statement, e.g:

m = require('match_it')
result = m.material(‘1877’)
return result

Form/list editing

The drTemplateParam default will contain the word ‘Create’ if the required action is to add a new object (customer record, material record, etc.). It will contain the word ‘Edit’ if the required action is to change an existing object.

For a ‘Create’ operation, register r01 is empty (actually a m.Void()) and register r02 contains the parent object if there is one (e.g. the sales order header for a sales order line).

For an ‘Edit’ operation, register r01 will contain the object to be edited and register r02 will contain its parent (if there is one).

In the case of using scripts to create method lines from the method editor, a method line can have a parent of a material record or a process library entry, here r02 is the material record and r03 is the process library entry.

In the case of attaching a script to the design button in the customer part record form, r01 contains the customer part record.

 

UI Hooks

When an expression is evaluated for a UI hook, the registers have the following meaning:

r01

The upper case window name invoking the expression.

r02

The upper case control name invoking the expression

r03

The upper case event name that was triggered, or 'ProcedureEntry' when the window is called, or 'ProcedureExit' when the window exits.

r04

The upper case 'when' name. One of 'pre' or 'post'. 'pre' is called before standard logic (but after 'sync') and 'post' is called after standard logic (but before 'refresh').

r05

For all events except 'ProcedureExit' this is the LocalRequest value. 1=InsertRecord, 2=ChangeRecord, 3=DeleteRecord, 4=SelectRecord.

For 'ProcedureExit' this is the LocalResponse value. 1=RequestCompleted, 2=RequestCancelled.

r06

The ForceRefresh flag (only meaningful in a 'post' call). When TRUE the standard logic is calling for a complete re-draw of the window controls and their values.

r07

The keycode active (if any) when the event was triggered.

PPS

When a script is invoked for a PPS expression, the registers have the following meaning:

r01
r02
r03

The ‘parent’ unit quantity, length and width.

r04

The ‘spec’ object. This is the ‘top’ thing that is creating the demand, e.g. a sales line.

r05

The ‘self’ object. This is either a material record (mch) or a method record (mcb).

r06

The make quantity. This is how much of the parent that is required.

r07

The demand material. This is the material that is required by the ‘spec’ object.

r08

The parent method line (mcb). This is the method record in the parent that is demanding this item. If the parent is the top, this will be empty.

r09

The ‘parent’ height.

r10

The 'like' root (mcb) or void if not in a LIKE process.