Progress.Lang.UserInterrupt class

(Technical Preview only in OpenEdge Release 11.7)

When enabled, and in most AVM contexts, the AVM throws an instance of this Progress.Lang.UserInterrupt class and raises the STOP condition when the user interrupts the AVM by pressing the STOP key, which is usually mapped to CTRL–C on Unix/Linux or CTRL–Break on Windows.

You can therefore catch instances of Progress.Lang.UserInterrupt in a CATCH block to trap each STOP condition raised when the user interrupts the AVM by pressing the OS interrupt key.

You cannot inherit from this class.

Serializable:

Yes

Constructors

The class constructors are reserved for system use only.

Super Class

Progress.Lang.Stop class

Interfaces

This class does not implement interfaces (beyond those it inherits from its base class).

Public Properties

This class does not contain properties (beyond those it inherits from its base class).

Public Methods

This class does not contain methods (beyond those it inherits from its base class).

Public Events

This class does not contain events.

Notes

In order to enable the AVM to throw Progress.Lang.UserInterrupt objects, you must specify the Catch STOP (-catchStop) startup parameter with the value 1 (-catchStop 1). Otherwise, the AVM raises the STOP condition only, without throwing the associated object.
In character mode only (running Linux, Unix, or character mode on Windows), when in the context of waiting for a record lock, pressing CTRL–C cancels this wait, then causes the AVM to both raise the STOP condition and throw a Progress.Lang.LockConflict object instead of throwing a Progress.Lang.UserInterrupt object as in any other AVM context. For more information, see the Progress.Lang.LockConflict class description.
By catching a UserInterrupt object with a CATCH block, you know what caused the AVM to raise the STOP condition and throw the object in the first place.
Note: You can instead trap the STOP condition using the ON STOP phrase on an associated block, but this does not tell you anything about what caused the AVM to raise the STOP condition itself.
Like any other class-based object that is no longer referenced, the AVM automatically deletes UserInterrupt objects using garbage collection.