Cadence User Interface Callback Routines

User interface objects can have callback routines associated with them. A callback is a SKILL routine that is asynchronously called back if some triggering user action takes place. Examples of such actions would be values being changed on forms, menu item selection, or dialog box confirmation. Typically, callbacks analyze and process data that you provide. In the case of forms, for example, a callback can be specified for each form field or for the form itself.

SKILL callbacks can be strings, symbols, or function objects. In any case, the string, the function specified by its symbol, or the function object, is evaluated in SKILL at the time the callback is triggered.

If the callback is:

a string, it must be a complete, valid SKILL expression because the string is passed directly to SKILL for evaluation.
a symbol, it is assumed that the value of this symbol is a function, and a predetermined set of arguments is passed to that function.
a function object, a predetermined set of arguments are passed to that function.

A function object callback offers the following advantages over the string and symbol types:

String and symbol callbacks are required to be in the global namespace. However, you need not define a function object type callback in the global namespace and if you define it in SKILL++, it is evaluated in the same environment in which it is defined.
When string and symbol callbacks are used, to access a field, you have to know where that field is used at the callback creation time. However, for a function object, you do not need to know the location of the field.

The functionality of callback routines follow the following guidelines:

They cannot return data on a stack. Instead, callback expressions return a value:
```
someSymbol = hiSomeRoutine(y)
```
In this example, someSymbol is a global SKILL symbol to be accessed later.
Make callbacks concise. In particular, avoid corrupting program data. As an example, the results can be unpredictable if a form callback modifies the form itself. Callbacks with destructive actions such as form modification, should be associated with actions that cannot be reversed, and cannot be done programmatically; that is, do not have a destructive action associated with a toggle button press (the toggle button has two states). This process can be simulated programmatically, doing so may unintentionally execute the destructive callback multiple times. In this case, the callback should be associated with a form button, which is an irreversible, non-programmatic action.
Avoid recursion in programming callbacks. This is a common mistake, and is easily demonstrated by a field callback which again sets the value of the field itself. Since callbacks are called when the value of the field changes, this would recursively continue calling the field callback, which sets the field value, which calls the field’s callback, which sets the field’s value, and so on.

If an error is detected in a callback routine, a dialog box should be brought up to flag the error, or an error logged in the CIW output panel. The field (type-in fields only) can be highlighted as well.

Cadence User Interface SKILL Reference
Product Version IC23.1, September 2023