Gate Events

A gate’s Events tab holds four small hooks. Each one runs a few commands at a moment in the gate’s life, so a model can count openings, log a closure, stamp a release time, or flip another gate.

The four hooks

Hook	Fires
On Open	When the gate goes from closed to open, once per opening
On Close	When the gate goes from open or releasing to closed
On Release	Once for every entity the gate releases
On Block	When an entity is blocked at the gate

On Open and On Close are dimmed on a gate running as Pull or as a Kanban control, with the reason on hover, because those gates are always open and neither event can ever happen. A Clear button appears when a hook already holds logic, and switching Pull or Kanban on clears whatever was stored there. On Release and On Block are always available, and they do fire under kanban.

What a hook can run

A gate hook runs action logic, minus what cannot wait. Write one statement per line, or separate them with semicolons. Do not write a section header: there are no sections here, and the placeholders show none. A hook’s own header (gate.OpenLogic in On Open, gate.CloseLogic in On Close) is passed over and the logic runs. The other hook’s header is refused ('gate.CloseLogic' is the header of On Close, not of On Open), and so is any other line that looks like a header.

Statements	In a hook
IF, WHILE, INC, DEC, SET, assignment, DISPLAY, LOG, SIGNAL, SEND, OpenGate, CloseGate, ToggleGate, ProcessTable, TAKE, STORE, INTERRUPT, and more	Allowed in all four hooks
Writing an attribute, NEWNAME	Allowed in On Release and On Block only
TIME, WAIT UNTIL, GET, USE, REQUEST, CALL, ROUTE, FREE, CREATE	Refused

A word that is not a statement is refused, not skipped. The hook stops with a message such as 'X' is not a statement this engine knows. A hook runs at one moment in the gate’s life, so keep it short and put work that has to wait in the action logic of the surrounding activities and routes.

Opening or closing a gate from a hook takes over the gate

OpenGate, CloseGate and ToggleGate do more than change the state once. From that moment the gate is under logic control for the rest of the run, and its schedule and its conditions stop governing it. That is useful when logic is meant to take charge, and a trap when it is not. Mixing an imperative call with a declarative schedule almost never ends up doing what was intended, so pick one.

Worked example

Counting is what these hooks are best at. Put this in On Open:

INC v_GateOpenings

and this in On Release:

INC v_Released

Both variables then appear in the report with their own statistics, giving you the number of openings and the number of entities let through.