Extended Triggers for OCX Container Widgets

An extended trigger is called by an OCX control when an OCX event takes place. The OCX container widget does not have a fixed set of extended triggers; rather, it depends on the OCX that is loaded into the container.

The extended triggers trigger is automatically filled by the OCX container widget. The default Proc code does nothing, but contains placeholders where you can enter Proc code.

If you do not define code for an extended trigger, you should remove or comment it out. This is especially true for OCX controls, which often have mouse and key events. If the extended triggers associated with these events are present in the trigger, Uniface attempts to call them, even if they contain no code, and this can cause performance problems.

If the Use Extended Triggers widget property is selected, OCX events are routed to extended triggers. If you have code (from earlier version of Uniface) that uses the Detail and Asynchronous Interrupt triggers to receive events, these triggers are also fired.

Uniface translates OCX data types to the appropriate Uniface data types. The OCX data type object is translated to handle.


It is not possible to use OUT or INOUT parameters with an extended trigger in an Uniface OCX container widget because these extended triggers are handled asynchronously. By the time Uniface can handle an OCX event, it has already been completely processed by the OCX control. The process sequence is as follows:

  • When an OCX event takes place, the OCX Container adds the event to an asynchronous message queue.

  • Uniface checks the message queue (or event queue) of the OCX container widget for new events when it is in an idle state.

  • If it finds new events, Uniface reads them from the queue and fires the corresponding extended trigger (if present).

It is also not possible to call a property or method of an OCX control from an extended trigger, because it is only valid within the context of a specific event. For example, the Accept method of the Microsoft Winsock control is valid only in the context of the ConnectionRequest event (see Accept Method in the MSDN for more information).