Für das Customizing von eEvolution®-Events kann zum einen der Customizer selbst eingesetzt werden oder ein speziell für diese Aufgabe eingerichteter Scripting-Editor verwendet werden. Dieser Scripting-Editor nennt sich Callout-Script-Verwaltung und ist durch die Tastenkombination Strg, Shift und einen Doppelklick mit der rechten Maustaste aufrufbar.
In diesem Dialog kann in der Feldgruppe
"Berechtigung für ausgewähltes Skript"
festgelegt werden, für welche Benutzer das Skript ausgeführt werden sollen.
Im Hauptfenster ist der
Mit den Knöpfen Ok
und Übernehmen wird der eingetragene
Code in die
In der Feldgruppe "Callout-Script" muss unter "bei Aktion" ein passendes Ereignis ausgewählt werden, wann der Code ausgeführt werden soll. Dabei werden folgende Events (jeweils in Pre_ und Post_-Form, also vor und nach Abarbeitung der eigentlichen Funktion) unterstützt:
Create
(SAM_Create des Windows in wc_gw_ParentWindow_MessageActions)
Die Ereignisse werden entweder vor oder nach dem Erzeugen des Fensters
ausgeführt.
Die Ereignisse werden vor oder nach dem Schließen des Fensters ausgeführt.
Das Ereignis wird vor oder nach dem Laden der Daten ausgeführt.
Das Ereignis wird vor oder nach dem Löschen von Daten ausgeführt.
Das Ereignis wird vor oder nach dem Drücken von OK
ausgeführt.
Das Ereignis wird vor oder nach dem Drücken von Übernehmen ausgeführt.
Das Ereignis wird vor oder nach dem Drücken von Abbrechen ausgeführt.
Diese Events können auch als "
Der Code wird in die Datenbank eingetragen.
Kommt es bei der Ausführung von einem Callout-Skript zu einem Fehler, so wird dieser in einer Messagebox ausgegeben:
In der Fehlermeldung werden die Modulnummer, der Dialogname und der Hook genannt, um den Fehler im Skript schnell beseitigen zu können.
Wichtig:
Skript-Fehler im Applikationsserver werden dort in die Ereignisausgabe geschrieben. Sowird verhindert, dass der Applikationsserver durch eine aufgehende Fehlermeldung an der Ausführung nicht mit der Fehlermeldung zusammenhängender Aufgaben gehindert wird.
Alternativ sind diese 
Allerdings muss hier darauf geachtet werden, dass für das anzupassende eEvolution®-Event der richtige Button bzw. das Hauptfenster ausgewählt wurde. Es werden die folgenden eEvolution®-Events unterstützt:
Load
(UMSG_F2Search im Hauptfenster der Module KuLiMi,
Artikel, AngAuf beim Laden von Datensätzen aus der DB in das Fenster)
Das Ereignis wird vor oder nach dem Laden der Daten ausgeführt.
Ist nur verfügbar wenn das Hauptfenster ausgewählt wurde.
Reset
(wird angewandt, bevor die Maske geleert wird, um die Eingabe neuer Daten
zu ermöglichen)
Das Ereignis wird vor oder nach dem Löschen von Daten ausgeführt.
Ok
(SAM_CLICK auf wc_pb_Ok)
Das Ereignis wird vor oder nach dem Drücken von OK
ausgeführt.
Apply
(SAM_CLICK auf wc_pb_Apply)
Das Ereignis wird vor oder nach dem Drücken von Übernehmen
ausgeführt.
Cancel
(SAM_CLICK auf wc_pb_Cancel)
Das Ereignis wird vor oder nach dem Drücken von Abbrechen
ausgeführt.
Der Scriptingcode des Customizers landet in der Customizerdeltadatei und NICHT in der Datenbank.
Das bisherige Scriptingkonzept sah vor, dass im Fehlerfall die Scriptmethode false zurückgibt: der Aufrufer stoppt dann die weitere Verarbeitung. Dies wird nun nachgebildet durch das Setzen von args.Cancel auf true.
Beispielsweise kann im PreOk-Handler noch einmal sicherheitshalber nachgefragt werden, ob der Datensatz wirklich abgespeichert werden soll. Falls der Benutzer sich dagegen entscheidet, sorgt das args.Cancel = true dafür, dass die SAM_CLICK-Nachricht nicht gesandt wird.
