1.4 handler

handler Einstieg

Der Begriff „handler“ wird Programmierern ein Begriff sein. Wer sich nicht auf auf Anhieb etwas darunter vorstellen kann, eine „Einsteigererklärung“: Ein handler im Ethos lua kann als eine Art Programm-Modul aufgefasst werden. Prinzipiell ist ein handler eine Programmroutine, die aufgrund eines übergeordneten (System) Ereignisses gestartet wird.

Es existieren verschiedene „spezialisierte“ Module/handler für verschiedene Aufgabengebiete, bzw für verschiedene „Ereignisse“ / Trigger wie z.B:

• Senderstart (Initialisierung)
• erster Aufruf
• Touch event
• Konfigurationsanpassung ……

Jedes Modul besitzt einen fest definierten Namen, eine Übersicht der handler ist unten aufgeführt. Jedes Modul, jeder handler ,führt durch den jeweils enthaltenen Programmablauf eine in sich geschlossene Routine aus, die seinem Aufgabengebiet entspricht. Der „Datenaustausch“ zwischen den handlern, falls gewünscht, findet dabei über eine einheitliche Datenstruktur, z.B. mit Namen „widget“, statt. Diese Datenstruktur wird sinnvollerweise beim Erstaufruf (durch den create handler) generiert.

Es folgt eine knappe Erläuterung zu den einzelnen handlern. Die detailliertere Funktionsweise wird sich aus Beispielscripten ergeben, die den einzelnen Kapiteln beigefügt sind.

Liste der typischen handler:

init()

Dieser handler wird während des Bootvorgangs des Senders aufgerufen.

Der handler wird verwendet, um dem Sender eine Liste aller Luas mit Ihren eindeutigen „Keys“ (eindeutige Schlüssel/identifier) und ihres Typs (widget, systemTool..) bekannt zu machen. Die „Umgebung“ (welche handler existieren im script) wird dabei ebenfalls eingerichtet.

Codebeispiel:

local function init()
    system.registerWidget({key="GV1" name="GVinflight" create=create paint=paint wakeup=wakeup configure=configure title=false read = read write = write} )
end

create()

Der create handler wird beim erstmaligen Aufruf des scripts ausgeführt, zum Beispiel wenn das erste mal der screen eines widgets aktiviert wird. Im create handler wird üblicherweise die „zentrale Datenstruktur / ein array definiert, dass an andere handler übergeben werden kann. Diese Datenstruktur muss als Rückgabewert des handlers definiert sein. Häufig (z.B. in einem widget), wird diese als widget benannt.

wakeup(widget)

Der wakeup handler ist der allgemeine Hintergrund handler für Aufgaben aller Art (alle Aufgaben außer denen, die in den unten aufgeführten handlern bearbeitet werden) Dazu gehört meistens das Auslesen von Quellen wie Schalterstellungen, Analog-Inputs, Telemetrie Werte, deren Verarbeitung, Aktualisierung der zentralen Datenstruktur. (Prinzip Eingabe, Verarbeitung Ausgabe). Er wird i.d. Regel rund dutzend mal per Sekunde aufgerufen Ein weiteres wesentliches Element liegt darin, die Entscheidung zu treffen, ob sich Daten verändert haben die für die Anzeige (im paint handler) relevant sind. Wenn ja triggert der wakeup handler durch die Methode lcd.invalidate() eine Aktualisierung des Displays. Idealerweise (aus Performancegründen) wird dabei der Bereich mit angegeben, der zu aktualisieren ist. Es dürfen mehrere Bereiche in einem wakup-Durchlauf angegeben werden.

paint(widget)

Der paint handler übernimmt die grafischen Darstellungen in einem script. Er ist daher nur in den scripten notwendig, die etwas auf das Display anzeigen, z.b. Widgets & Systemscripte, aber nicht Source scripte. Nur hier haben die Methoden/Funktionen zum Zeichnen, Text und Wertedarstellung etwas verloren (lcd Klasse). Idealerweise hat der wakeup handler alle notwendigen Texte, Werte und sonstigen Variablen vorverarbeitet, so dass hier fast nur noch zur Präsentation relevante Programmblöcke vorhanden sind.

Hinweis:

In Forum tauchen immer wieder Verständnisprobleme über das Zusammenwirken des wakeup handlers, des paint handlers, und der lcd.invalidate() Methode .

Allgemein sollte es so aufgefasst werden:

• wakeup ist für die allgemeine Hintergrundverarbeitung und damit auch (soweit es möglich ist) zur Vorverarbeitung der in paint verwendeten Daten zuständig. Wakeup wird sehr häufig vom System aufgerufen.

• paint wird ebenfalls häufig vom System aufgerufen, „folgt“ dem wakeup handler quasi. Schwerpunkt liegt in der grafischen Präsentation. GANZ WICHTIG: Der Aufruf einer grafischen Methode wie zum Beispiel das Zeichnen von Linien, „Drucken“ von Texten oder Werten etc., heißt NICHT zwangsläufig, dass dies auch direkt auf dem Bildschirm angezeigt wird, es wird quasi zunächst ein sehr schneller Bild-Zwischenspeicher gefüllt

• lcd.invalidate(x,y,w,h): erst dieser call führt dazu, dass der Bildschirm (bzw der angegebene Bereich) am Display gelöscht, und der relativ „langsame“ Bildschirmspeicher mit neuen Daten gefüllt wird. Die Methode sollte nur von Wakeup aus aufgerufen werden. idealerweise wenn festgestellt ist, dass sich etwas an der Darstellung aktualisiert hat !

Die Tatsache, dass der Durchlauf von paint nicht zwangsläufig zu einem Bildschirmrefresh führt kann für Einsteiger verwirrend sein, hat aber deutliche Performancevorteile für das gesamte System

event(widget category value x y)

Dieser handler dient zur Verarbeitung von „äußeren Events“, in der Regel Benutzerinterventionen. Beispielsweise Touch eines Screens, Drücken von Bedientasten (Page Up/down), Scrollrad etc… Man sieht oben, dass außer der typischen „widget“ Struktur, seitens Ethos noch die Kategorie (z.B. touch event), der Wert (drücken / loslassen) und Koordinaten als Eingangsparameter mit übergeben werden.

configure(widget)

Wer bereits mit widgets gearbeitet hat, kennt ggf. die Möglichkeit diese über einen Menüaufruf zu konfigurieren. Dieser Aufruf triggert den config handler. Es stehen insbesondere Möglichkeiten zur Verfügung, via forms Klasse ein umfangreiches Config Menü zu gestalten.

write(widget)

Über den write handler werden modellspezifische Parameter in die Modelldatei weggespeichert. Typischerweise triggern Änderungen der Werte im Config handler diese Schreibaktion. Dazu muss der handler natürlich bereits durch den init handler definiert worden sein (-;

read(widget)

Die durch den write handler geschriebenen Parameter sollen natürlich auch beim Laden des Modells (oder anderweitig) geladen werden können. Dies geschieht durch den read handler.

menu(widget)

Handler, der bei der Erstellung des Kontextmenüs aufgerufen wird, um das Hinzufügen weiterer Optionen zu ermöglichen

close(widget)

Handler der aufgerufen wird, wenn die aktuelle Seite geschlossen wird