2 Events

on <object ID> <event> { , <event> }

Example

on Pushbutton select

{

  Action;

}

The following event types are provided by the IDM.

2.1.1 Objects and their User Events

All events which can be triggered by the user for an object are listed in the following chart.

Note for IDM on Microsoft Windows

The event "dbselect" is always carried out without "activate" and "deactivate", because they have already been created in the former "select"-event.

Examples for Event Lines

• on dialog start
  {
    program block
    /* execution on DM program start */
  }

• on WINDOW close
  {
    program block
    /* on closing any window, i.e. on
       activation of close button */
  }

• on OK_Button select
  {
      program block
      /* on activation of OK_Button */
  }

• on Window.title changed
  {
    program block
    /* on change of window title */
  }

• on Window.title changed
  if ( Variable_1 = 12 )
  {
    program block
    /* on change of window title
       AND if Variable_1 contains the value 12 */
  }

2.1.2 Drag and Drop Events

In this chapter the events which are triggered by Drag&Drop operations are described. As with clipboard actions the relevant events are sent to the object. A Drag&Drop operation triggers a cut event at the source object and a paste event at the target object.

Note: The order of the events is arbitrary!

The Drag&Drop here described currently works on Microsoft Windows systems only.

2.1.2.1 Cut Event

On cutting the IDM does not automatically carry out a delete action, but reacts to the cut event. The attributes thisevent.type and thisevent.value are invalid and thus not used.

2.1.2.2 Paste Event

This event triggers a paste reaction.

thisevent.type contains a type_enum and shows the assumed format.

thisevent.value contains the data (DM data type).

When processing, note that .cut_pending = true, if the source object and target object are the same in a move operation (Cut + Paste).

2.1.2.3 Examples

The examples for these events are in directory …\examples\dragdrop.

Module with Standard Rules

The module dnd_defa.mod contains rules for the standard behavior of several objects.

Currently there are rules for Cut and Paste with the format type_text available for the objects edittext, listbox and tablefield.

Plain Rules

• rule boolean DnD_default_cut (object Obj input);

  Cut rule calling the corresponding rule for an object

• rule boolean DnD_default_paste (object Obj input, anyvalue Event input);

  Paste rule calling the corresponding rule for an object

Special Rules

• rule boolean Edittext_cut (object Obj);
• rule boolean Edittext_paste (object Obj, anyvalue Type, anyvalue Value, anyvalue Index);
• rule boolean Listbox_cut (object Obj);
• rule boolean Listbox_paste (object Obj, anyvalue Type, anyvalue Value, anyvalue Index );
• rule boolean Tablefield_cut (object Obj);
• rule boolean Tablefield_paste (object Obj, anyvalue Type, anyvalue Value, anyvalue Index );

The return value of all rules indicates whether the processing has been executed successfully.

Dialog dnd_et.dlg

This dialog is a Drag&Drop example for an edittext. The rules of the module dnd_defa.mod are used.

Dialog dnd_lb.dlg

This dialog is a Drag&Drop example for a listbox. The rules of the module dnd_defa.mod are used.

Dialog dnd_tb.dlg

This dialog is a Drag&Drop example for a tablefield. The rules of the module dnd_defa.mod are used.

Dialog solitair.dlg

This stand-alone dialog illustrates how to use the Drag&Drop data type type_object.

2.1.2.4 Tips & Tricks for Drag & Drop and Clipboard

Cut rules and paste rules should always be able to operate independently, because of the following aspects:

• The source and the target are often different objects which do not necessarily occur in one and the same application.
• Depending on the user input the order of the events may be arbitrary. It is e.g. possible to cut or copy once via keyboard at one and the same object, carry out a Drag&Drop operation and two hours later insert 10x.

As soon as "Cut" is allowed at an object, this operation may be triggered at any time. Before the rule "on Cut" is executed other rules might access the object. To avoid that important information is inadvertently falsified, the attribute .cut_pending is set to true.

This is why you should note the following when programming:

As long as .cut_pending = true no attributes can be changed at the object, i.e. rules, which might be called between the "Cut" triggering and the cut event (e.g. by on focus), cannot change the object per default.

Attention

In a Drag&Drop move operation on one and the same object, the paste event occurs before the cut event, i.e. with .cut_pending = true.

If, nevertheless, a rule is to reset attributes you may set .cut_pending := false. To inform the following cut rule you should set .cut_pending_changed := true.

For the processing of the format DM_Object in the paste rule you should check if the object really is available at that moment.

2.1.3 User Events with Special Inheritance

To process also key events in the ISA Dialog Manager Rule Language, these key events can be queried as follows:

on <object ID> key <accelerator>

<object ID>

Name of an object, a Model or a Default defined in the dialog.

<accelerator>

Name of an accelerator defined in the dialog.

This event is internally inherited in the IDM according to the following scheme, so that a rule has not to be defined for each object (if, e.g., the key F1 was pressed).

This inheritance is interrupted as soon as one of these objects has defined a rule for this key.

Example

dialog Example
accelerator FK5
{
  0: F5;
}

window Window
{
  .xleft  10;
  .width  100;
  .ytop   10;
  .height 200;

  child pushbutton
  {
    .xleft 10;
    .ytop  10;
    .text  "pushbutton";
  }
}

on Example key FK5
{
  print "Key F5 was pressed";
}

The rule is executed as soon as F5 is pressed in this window.

The same mechanism of hierarchical inheritance is valid for the help event, i.e. only one rule is responsible for help. This rule is attached to the dialog.

2.2 Internal Events

Events referring to the change of an object attribute or of a variable are called internal events.

on <object ID><attribute name> changed

Please refer to the descriptions in the “Attribute Reference” for the attributes which can be used here.

The following is valid for variables:

on <variable name>.value changed

See Also

Attribute value

Examples

• on Variable_A.value changed

  {

  }

• on Pushbutton.xleft changed

  {

  }

2.3 System Events

Events which refer to the entire IDM program system are called system events. These events are used to formulate rules for dialog or module starts and dialog or module ends.

The same applies to the object application.

Start Rule

on dialog start
  Event that indicates the start of the IDM program processing.

on module start
  Event that indicates the start of the module processing.

on application start
  Event that indicates the start of an application object processing.

Finish Rule

on dialog finish
  Event that indicates the end of the IDM program processing.

on module finish
  Event that indicates the end of the module processing.

on application finish
  Event that indicates the end of an application object processing.

The following system events are possible:

Examples

• on dialog start

  {

  }

• on dialog finish

  {

  }

Typically, the start rule contains statements for initializing data, the finish rule contains statements for a controlled exiting of the IDM (e.g. closing all windows).

The start rule should always be defined; at least one rule containing the keyword exit must be defined in addition.

Execution of the rule containing the keyword exit calls the finish rule.

2.4 External Events

External events are events that are to be treated equally to the dialog events in the ISA Dialog Manager as concerns their assignment and their processing. However, their source is not controlled by the IDM. One possible source of such events can e.g. be a signal handler which generates this event so that the dialog can respond to it.

An external event is a mixture of dialog event and parametrized rule.

As with parametrized rules, the number of parameters is limited to 16.

It has to be noted though, that only 14 parameters are usable when used from Rule Language. Therefore it is reasonable to define external events with a maximum of 14 parameters (see also built-in function sendevent()).

on <object ID> extevent <event ID> ([<data type> <parameter name> <type>])

anyvalue <event ID>

Indicates an identifier that is unique for the respective object and refers to the external event. For instance, a message resource may be used here.

External events are sent to an object and then passed to the object's Default until an object processes the event.

Example

on Object1 extevent 4711 (integer ErrCode, string ErrText);

on Object2 extevent EvSave (boolean Success, string Text);

The execution of a rule attached to an external event is registered by the application with the interface functions DM_QueueExtEvent or DM_SendEvent.Registered means that the rule is not executed immediately, but that the external event is queued and then processed according to the dialog event mechanisms.

See Also

C functions DM_QueueExtEvent and DM_SendEvent in manual “C Interface - Functions”