2 Ereignisse

Die Ereigniszeile wird durch das Schlüsselwort on eingeleitet.

Jede Regel darf dabei maximal eine Ereigniszeile haben, die aber aus mehreren Ereignissen für ein Objekt bestehen kann.

Die regelauslösenden Ereignisse lassen sich in die folgenden Gruppen einteilen:

Benutzerereignisse,
Tastatur- und Hilfe-Ereignisse,
interne Ereignisse,
Systemereignisse,
externe Ereignisse.

2.1 Benutzerereignisse

Ereignisse, die sich auf ein bestimmtes Objekt, eine Vorlage oder eine Objektklasse beziehen, werden Benutzerereignisse genannt. Für diese Art von Ereignissen ist entscheidend, dass bei allen der Benutzer als Ursache für das Auftreten des Ereignisses verantwortlich ist. Immer wurden Aktionen vom Benutzer ausgeführt, die dazu geführt haben, dass das entsprechende Ereignis ausgelöst worden ist.

Die Syntax für diese Art von Ereigniszeile sieht wie folgt aus:

on <Objekt-ID> <Ereignis> { , <Ereignis> }

Wie man dabei dieser Definition entnehmen kann, kann eine Regel an nur ein Objekt, aber an mehrere durch Kommata getrennte Ereignisse gebunden sein.

Objekt-IDs sind die Namen für bestehende DM-Objekte (Identifikatoren) wie z.B. OK_Knopf, TestFenster usw.).

Ereignistypen beschreiben benutzerinitiierte Ereignisse wie selektiert, bewegt, geschlossen.

Beispiel

on Pushbutton select

{

Aktion;

}

Bei Clipboard-Aktionen werden die entsprechenden Events an das Objekt geschickt. Eine Drag & Drop-Operation löst beim Quellobjekt beim Cut einen Cut-Event aus und am Zielobjekt einen Paste-Event. Da bei einem Objekt bei Copy nichts verändert wird, gibt es keinen Copy-Event.

Achtung: Die Reihenfolge der Events ist willkürlich!

Beim Cut wird vom DM aus keine Löschaktion vorgenommen. Die Reaktion muss auf den Cut-Event hin erzeugt werden. Die Attribute thisevent.type und thisevent.value sind nicht belegt.

Die Paste-Reaktion kann mit diesem Event ausgelöst werden.

thisevent.type enthält einen type_enum und zeigt das angenommene Format an.

thisevent.value enthält die Daten (DM_Datentyp).

Bei der Bearbeitung sollte man darauf achten, dass .cut_pending = true ist, wenn Quell- und Zielobjekt bei einer Move-Operation (Cut + Paste) das gleiche sind.

Die Beispiele hierzu befinden sich im Verzeichnis ...\examples\dragdrop.

Folgende Ereignistypen stellt der DM zur Verfügung:

Ereignistyp	Beschreibung
activate	Das angegebene Objekt wurde aktiviert. Dieses Ereignis kann für alle Objekte ausgelöst werden, deren aktiver Zustand deutlich für den Benutzer sichtbar ist.
changed	Der Wert einer angegebenen Variable oder eines angegebenen Objektattributs wurde geändert.
charinput	Ein Zeichen wurde in einen editierbaren Text eingegeben. Kann nun z.B. geprüft werden.
close	Schließmechanismus (z.B. Closebox) eines Fensters wurde betätigt. Bei einem Treeview wurde ein Teilbaum geschlossen.
cut	Benutzer hat mit Drag&Drop ein Objekt ausgeschnitten.
dbselect	Benutzer hat das Objekt durch einen Doppelklick selektiert, d.h. ein Objekt editiert.
deactivate	Benutzer hat ein Objekt deaktiviert, z.B. wenn er eine bereits aktivierte Checkbox nochmals selektiert, so dass diese nun deaktiviert wird.
deiconify	Icon wurde wieder zu einem Fenster geöffnet.
deselect	Objekt wurde deselektiert (durch Anwahl eines anderen Objekts oder durch Beenden der Eingabe mit `Return`-Taste beim editierbaren Text).
deselect_enter	Eingabe in das Textfeld wurde durch das Drücken der `Return`-Taste beendet.
extevent	Externes Ereignis ist aufgetreten.
finish	Ende des Dialoges oder Moduls oder Beenden einer Verbindung zu einer Applikation.
focus	Eingabefokus wurde auf das angegebene Objekt gesetzt.
help	Benutzer hat für das aktuelle Objekt Hilfe angefordert. Die Anforderung der Hilfe erfolgt dabei so, wie es das jeweilige Fenstersystem vorsieht (z.B. für Motif & Windows: `F1`-Taste, unter Qt Tastenkombination `SHIFT`+`F1`).
hscroll	Der Benutzer hat horizontal gescrollt.
iconify	Iconifybox eines Fensters wurde betätigt; -> Fenster wird dadurch zum Icon.
key	Benutzer hat für das Objekt, für das diese Regel geschrieben wurde, den nach dem Schlüsselwort key angegebenen Accelerator gedrückt (siehe auch Kapitel „Benutzerereignisse mit besonderer Vererbung“).
modified	Benutzer hat das Editieren eines Textes beendet und diesen dabei aktiv verändert.
move	Benutzer hat das Fenster verschoben. Eine Toolbar wurde verschoben. Bei einer eingedockten Toolbar tritt das Ereignis nur auf, wenn sich durch das Verschieben die Attribute .dock_offset oder .dock_line ändern.
open	Eine Menübox wurde geöffnet. Bei einem Treeview wurde ein Teilbaum geöffnet.
paste	Der Benutzer hat ein Objekt mit Hilfe von Drag&Drop verschoben und über einem anderen Objekt losgelassen.
resize	Fenster wurde in seiner Größe verändert. Bei einer Splitbox wurde die Größe eines Splitbereichs geändert.
scroll	Benutzer hat gescrollt.
select	Objekt wurde vom Benutzer selektiert.
start	Start des Dialoges, Moduls oder Verbindungsaufbau einer Applikation.
vscroll	Der Benutzer hat vertikal gescrollt.

Beispiele für Ereigniszeilen

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.1 Drag und Drop-Ereignisse

In diesem Kapitel werden die Ereignisse beschrieben, die durch Drag&Drop-Operationen ausgelöst werden. Wie bei Clipboard-Aktionen werden die entsprechenden Events an das Objekt geschickt. Eine Drag & Drop-Operation löst beim Quellobjekt beim Cut einen Cut-Event aus und am Zielobjekt einen Paste-Event.

Achtung: Die Reihenfolge der Events ist willkürlich!

Das hier beschriebene Drag & Drop funktioniert zur Zeit nur auf den Microsoft Fenstersystemen.

2.1.1.1 Cut-Event

Beim Cut wird vom DM aus keine Löschaktion vorgenommen. Die Reaktion muss auf den Cut-Event hin erzeugt werden. Die Attribute thisevent.type und thisevent.value sind nicht belegt.

2.1.1.2 Paste-Event

Die Paste-Reaktion kann mit diesem Event ausgelöst werden.

thisevent.type enthält einen type_enum und zeigt das angenommene Format an.

thisevent.value enthält die Daten (DM_Datentyp).

Bei der Bearbeitung sollte man darauf achten, dass .cut_pending = true ist, wenn Quell- und Zielobjekt bei einer Move-Operation (Cut + Paste) das gleiche sind.

2.1.1.3 Beispiele

Die Beispiele zu den hier beschriebenen Ereignissen befinden sich im Verzeichnis …\examples\dragdop.

Modul mit Standard-Regeln

Das Modul dnd_defa.mod enthält Regeln für das Standardverhalten einiger Objekte.

Derzeit sind Regeln zur Behandlung von Cut und Paste des Formats type_text für die Objekte Edittext, Listbox und Tablefield enthalten.

Allgemeine Regeln

rule boolean DnD_default_cut (object Obj input);

Cut-Regel, die je nach Objekt die passende Regel aufruft
rule boolean DnD_default_paste (object Obj input, anyvalue Event input);

Paste-Regel, die je nach Objekt die passende Regel aufruft

Spezielle Regeln

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 );

Der Rückgabewert aller Regeln zeigt an, ob die Bearbeitung erfolgreich ausgeführt werden konnte.

Dialog dnd_et.dlg

Dieser Dialog ist ein Drag&Drop-Beispiel für einen Edittext. Die Regeln aus dem Modul dnd_defa.mod werden hier verwendet.

Dialog dnd_lb.dlg

Dieser Dialog ist ein Drag&Drop-Beispiel für eine Listbox. Die Regeln aus dem Modul dnd_defa.mod werden hier verwendet.

Dialog dnd_tb.dlg

Dieser Dialog ist ein Drag&Drop-Beispiel für ein Tablefield. Die Regeln aus dem Modul dnd_defa.mod werden hier verwendet.

Dialog solitair.dlg

Dieser Stand-alone Dialog zeigt, wie der Drag&Drop-Datentyp type_object verwendet werden kann.

2.1.1.4 Tipps & Tricks zu Drag & Drop und Clipboard

Cut-Regeln und Paste-Regeln sollten immer unabhängig von einander arbeiten können. Dafür gibt es folgende Gründe:

Quelle und Ziel sind oft verschiedene Objekte, die sich nicht einmal in der gleichen Applikation befinden müssen.
Je nach Benutzereingabe können die Events in beliebiger Reihenfolge kommen. Der Benutzer kann z.B. am gleichen Objekt einmal über Tastatur ausschneiden oder kopieren, eine Drag & Drop-Operation ausführen und zwei Stunden später 10x einfügen.

Sobald an einem Objekt "Cut" erlaubt wird, kann diese Operation an jedem Zeitpunkt ausgelöst werden. Bis die "on cut" Regel ausgeführt wird, könnten andere Regeln vorher auf das Objekt zugreifen. Damit nicht versehentlich wichtige Informationen, auf die sich die Cut-Regel verlässt, verfälscht werden, wird das Attribut .cut_pending auf true gesetzt.

Aus diesen Gründen ist bei der Programmierung folgendes zu beachten:

Während .cut_pending = true ist, können am Objekt keine Attribute verändert werden. D.h. Regeln, die unter Umständen zwischen dem Auslösen des "Cuts" und dem cut-Event aufgerufen werden könnten (z.B. durch on focus), können per Default nichts am Objekt verändern.

Achtung

Bei einer Drag & Drop Move-Operation auf dem selben Objekt, kommt der Paste-Event vor dem Cut-Event, also mit .cut_pending = true.

Wenn eine Regel trotzdem Attribute neu setzen soll, kann .cut_pending := false gesetzt werden. Damit die nachfolgende Cut-Regel dies bemerken kann, wird dabei .cut_pending_changed := true gesetzt.

Bei der Verarbeitung des Formats DM_Objekt, in der Paste-Regel, sollte geprüft werden, ob das Objekt tatsächlich zu diesem Zeitpunkt existiert.

2.1.2 Benutzerereignisse mit besonderer Vererbung

Um in der Regelsprache des DM auch Tastaturereignisse verarbeiten zu können, können diese wie folgt abgefragt werden:

on <Objekt-ID> key <accelerator>

<Objekt-ID>: Name eines im Dialog definierten Objekts, Modells oder Defaults.
<accelerator>: Name eines im Dialog definierten Accelerators.

Damit nicht für jedes Objekt eine Regel definiert werden muss (z.B. ob die Taste F1 gedrückt wurde), wird dieses Ereignis intern im DM nach folgendem Schema vererbt:

Abbildung 20-1: Vererbung bei Key- und Help-Regeln

Diese Vererbung wird unterbrochen, sobald eines dieser Objekte eine Regel für diese Taste definiert hat.

Beispiel

dialog Beispiel
accelerator FK5
{
  0: F5;
}

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

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

on Beispiel key FK5
{
  print "Taste F5 wurde gedrückt";
}

Sobald die Taste F5 in diesem Fenster gedrückt wurde, wird die Regel ausgeführt.

Derselbe Mechanismus hierarchischer Vererbung gilt für das Hilfe-Ereignis. Dadurch wird erreicht, dass nur eine Regel für die "Hilfe" zuständig ist, die am Dialog hängt.

2.2 Interne Ereignisse

Ereignisse, die sich auf die Änderung eines Objektattributes oder einer Variable beziehen, sind interne Ereignisse.

on <Objekt-ID><Attributname> changed

Die Attribute, die hier verwendet werden können, entnehmen Sie bitte den Beschreibungen in der „Attributreferenz“.

Für Variablen gilt folgendes:

on <Variablenname>.value changed

Beispiel

on Variable_A.value changed

{

}

on Pushbutton.xleft changed

{

}

2.3 Systemereignisse

Ereignisse, die sich auf das gesamte DM-Programm-System beziehen, werden Systemereignisse genannt. Mit Hilfe dieser Ereignisse lassen sich Regeln für den Dialog- oder Modulstart und das Dialog- oder Modulende formulieren.

Dasselbe gilt auch für das Objekt application.

Start-Regel

on dialog start
  Ereignis, das den Beginn der Abarbeitung des DM-Programms anzeigt.

on module start
  Ereignis, das den Beginn der Abarbeitung des Moduls anzeigt.

on application start
  Ereignis, das den Beginn der Abarbeitung des application-Objektes anzeigt.

Ende-Regel

on dialog finish
  Ereignis, das das Ende der Abarbeitung des DM-Programms anzeigt.

on module finish
  Ereignis, das das Ende der Abarbeitung des Moduls anzeigt.

on application finish
  Ereignis, das das Ende der Abarbeitung des application-Objektes anzeigt.

Folgende Systemereignisse sind möglich:

Ereignistyp	Beschreibung
application start	Ereignis, das den Start der Abarbeitung des Application-Objektes anzeigt.
application finish	Ereignis, das das Ende der Abarbeitung des Application-Objektes anzeigt.
dialog start	Ereignis, das den Start der Dialogabarbeitung anzeigt.
dialog finish	Ereignis, das das Ende der Dialogabarbeitung anzeigt.
module start	Ereignis, das den Start des Moduls anzeigt.
module finish	Ereignis, das das Ende des Moduls anzeigt.

Beispiel

on dialog start

{

}

on dialog finish

{

}

Typischerweise beinhaltet die Start-Regel Statements, um Daten zu initialisieren, die Ende-Regel beinhaltet Statements für ein kontrolliertes Verlassen des DM (z.B. für das Schließen aller Fenster).

Die Start-Regel sollte immer definiert werden; zusätzlich muss mindestens eine Regel definiert werden, die das Schlüsselwort exit beinhaltet.

Die Ausführung der Regel, die das Schlüsselwort exit beinhaltet, ruft die Ende-Regel auf.

2.4 Externe Ereignisse

Externe Ereignisse sind Ereignisse, die zwar von ihrer Zuordnung und Abarbeitung her mit den Dialogereignissen im ISA Dialog Manager gleichzustellen sind, deren Quelle allerdings nicht unter der Kontrolle des IDM steht. Eine mögliche Quelle solcher Ereignisse kann z.B. ein Signal-Handler sein, der dieses Ereignis erzeugt, damit der Dialog darauf reagieren kann.

Ein externes Ereignis stellt eine Mischung aus Dialogereignis und parametrisierter Regel dar.

Wie bei den parametrisierten Regeln ist die Anzahl der Parameter auf 16 limitiert.

Allerdings ist zu beachten, dass bei der Nutzung aus der Regelsprache nur 14 Parameter verwendet werden können und es daher sinnvoll ist, externe Ereignisse mit maximal 14 Parametern zu definieren (siehe auch eingebaute Funktion sendevent()).

on <Objekt-ID> extevent <Ereignis-ID> ([<Datentyp> <Parametername> <Typ>])

anyvalue <Ereignis-ID>: Bezeichnet einen für das jeweilige Objekt eindeutigen Identifikator, über den das externe Ereignis referenziert wird. Hier kann beispielsweise auch eine message-Ressource genutzt werden.

Externe Ereignisse werden an ein Objekt geschickt und von dort bis zum Default des Objekts weitergereicht bis ein Objekt das Ereignis verarbeitet.

Beispiel

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

on Object2 extevent EvSpeichern (boolean Erfolg, string Text);

Die Ausführung einer dem externen Ereignis zugeordneten Regel wird durch die Anwendung über die Schnittstellenfunktionen DM_QueueExtEvent oder DM_SendEvent vorgemerkt. Vorgemerkt bedeutet, dass die Regel nicht sofort ausgeführt wird, sondern dass das externe Ereignis in eine Queue eingetragen wird und entsprechend den Mechanismen für Dialogereignisse weiterverarbeitet wird.

Siehe auch

C-Funktionen DM_QueueExtEvent und DM_SendEvent im Handbuch „C-Schnittstelle - Funktionen“