The Form and Menu Language

Interrupt signal handling

Prior to Release 4.0 of FMLI, the only way an executable invoked from within an FMLI application could be interrupted was if it was invoked as an argument to the built-in utility run (except when the -s option is specified).

In FMLI Release 4.0 or later, executables initiated in a backquoted expression that is the value of either the action or done descriptors--wherever they occur in your application--can also be designated as interruptible through the use of the interrupt descriptor. No other descriptors of type command (help, rmenu, and oninterrupt) are affected by the interrupt descriptor.

The Boolean descriptor interrupt defines whether or not an executable can be interrupted by the user. It always defaults to FALSE. A companion to interrupt, the command descriptor oninterrupt, defines what will be done when the interrupt signal (SIGINT) is received. It always defaults to `message Operation interrupted!`nop. The value of oninterrupt can be any action normally permitted for a command descriptor (both backquoted expressions and FMLI commands). The oninterrupt descriptor is ignored if interrupt has not been defined anywhere in your application or if interrupt evaluates to FALSE.

Depending on the kind of frame definition file or application level file they are used in, these two descriptors are independently subject to one of several inheritance hierarchies (see ``Inheritance hierarchies used to determine the values of interrupt and oninterrupt when interrupt key is pressed'', a table of inheritance hierarchies for interrupt and oninterrupt).

NOTE: The status of the interrupt descriptor only affects executables in backquoted expressions. Its status does not affect FMLI commands (such as cancel), built-in utilities other than run (such as shell), or any of their child processes. Nor does it affect processes run from FMLI that ``take over the screen,'' such as the shell obtained by using the unix-system command from the command menu. (In these cases, interrupt handling is done by the full-screen application.)

The interrupt status in effect for an action or done descriptor applies to all executables in the descriptor. However, if the executable that is being executed when the interrupt signal is received has itself been coded to ignore interrupts, it will complete its normal execution, but remaining commands in the descriptor will not be executed. (FMLI built-in utilities behave the same as executable utilities that have been coded to ignore interrupts.) When an executable is interrupted, any commands (built-in utilities and FMLI commands, as well as other executables) remaining in the descriptor are ignored by the interpreter. Instead, whatever you have defined to be the value of the oninterrupt descriptor will be executed.

The scope of interrupt is independent from the scope of oninterrupt, and each depends on where it is coded. The highest level in the inheritance hierarchy is the one in effect for the current action or done descriptor. For example, coding interrupt=true once, in the general descriptors section of an initialization file, means that all executables in any action or done descriptor anywhere in your application (including any in the commands file or defined for SLKs) can be interrupted by the user.

Continuing this example, if interrupt=false is then coded with the frame descriptors in a menu definition file, then the status of FALSE is inherited by all items defined for that menu, while all executables in all other frames remain interruptible. Going one step further, if interrupt=true is coded with the item descriptors for one item in that menu, then executables coded in that item's action descriptor will be interruptible by users, and all other items will remain uninterruptible. Inheritance of the value of the oninterrupt descriptor is handled the same way, but is completely distinct from the interrupt descriptor.

These descriptors can also be defined in the commands file (see ``Application level definition files'' for a discussion of the commands file). If interrupt or oninterrupt are not defined for a command in the commands file, that command will inherit the value of interrupt and/or oninterrupt defined with the general descriptors in the initialization file. If not defined there, the FMLI default value is inherited.

Inheritance of these two descriptors is handled slightly differently for screen-labeled function keys. Redefining a SLK in a frame definition file completely overrides a definition of it you may have coded in the initialization file. For example, if you define interrupt for a particular SLK in the initialization file, but do not include interrupt in a redefinition of that SLK in a frame definition file, the SLK will inherit the value of the interrupt descriptor defined at the next lower inheritance level (from the frame descriptors if defined there, then from the general descriptors in the initialization file if defined there, then from the FMLI defaults).

The table in ``Inheritance hierarchies used to determine the values of interrupt and oninterrupt when interrupt key is pressed'' summarizes the inheritance hierarchies for both descriptors wherever they can be used:

Inheritance hierarchies used to determine the values of interrupt and oninterrupt when interrupt key is pressed

Executables coded in

Inheritance level action descriptor in menu items action descriptor in SLK definitions action descriptor in command definitions

done descriptor in any frame

1 (lowest) FMLI defaults FMLI defaults FMLI defaults FMLI defaults

2 values coded with the general descriptors in an initialization file values coded with the general descriptors in an initialization file values coded with the general descriptors in an initialization file values coded with the general descriptors in an initialization file

3 values coded with the frame descriptors in a menu definition file values coded with the frame descriptors in a frame definition file values coded in the commands file values coded with the frame descriptors in a frame definition file

4 values coded with the item descriptors in a menu definition file values coded with the SLK descriptors in an initialization file* n/a n/a

5 (highest) n/a values coded with the SLK descriptors in a frame definition file* n/a n/a

	Executables coded in
Inheritance level		action descriptor in menu items	action descriptor in SLK definitions	action descriptor in command definitions
done descriptor in any frame
1 (lowest)	FMLI defaults	FMLI defaults	FMLI defaults	FMLI defaults
2	values coded with the general descriptors in an initialization file	values coded with the general descriptors in an initialization file	values coded with the general descriptors in an initialization file	values coded with the general descriptors in an initialization file
3	values coded with the frame descriptors in a menu definition file	values coded with the frame descriptors in a frame definition file	values coded in the commands file	values coded with the frame descriptors in a frame definition file
4	values coded with the item descriptors in a menu definition file	values coded with the SLK descriptors in an initialization file*	n/a	n/a
5 (highest)	n/a	values coded with the SLK descriptors in a frame definition file*	n/a	n/a

*: SLK-specific descriptors in a frame definition file completely override SLK descriptors defined in the initialization file. If either the interrupt or oninterrupt descriptor, or any other SLK-specific descriptor, is coded at level 5 (highest inheritance level), then all SLK-specific descriptors coded at level 4 are ignored.