Skip to main content
Skip table of contents

(v13) Permission events

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP

More use can be made of the handler's return code by using it to indicate to the Event issuer whether something should occur.

An example of this can be found in progevts.c , which provides the implementation of

clrip's -n option. A high priority handler is installed for the SWEVT_MONITOR Event:

TEXT
                      static sw_event_handler progress_handler = {
                        progressFilter, /* handler */ &suppressedProgressTypes /* context */
                      };
                      SwRegisterHandler(SWEVT_MONITOR, &progress_handler, MON_FILTER)

The handler checks the type of each Event to determine if it should be suppressed. Suppression is implemented by progressFilter () returning SW_EVENT_HANDLED:

if (suppressedTypes & messageType) return SW_EVENT_HANDLED;

which prevents any lower priority handler receiving the Event.

Other handlers for the SWEVT_MONITOR event will only be called for the unsuppressed types (that is, those for which progressFilter () returns SW_EVENT_CONTINUE).

Much like the RDR system it is based on, the Event system does not dictate how a protocol is implemented, so care must be taken to consider the best representation in the face of multiple handlers, expected Priorities, and error conditions.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.