30 Aug 2006 

Zap-Reiz

Das kommt häufiger vor. Beim Laden des Formulares werden komplexere Berechungen ausgeführt. Dann dauert das Laden seine Zeit und solange ist ein leeres Fenster zu sehen. → Zap-Reiz!

Im verwendeten Beispiel wird eine Kreuztabelle (Pivot) erzeugt. In den Zeilen sind die Teilnehmer und in den Spalten die Veranstaltungen gelistet. In den Zellen der Schnittpunkte stehen die Ergebnisse je Teilnehmer und Veranstaltung. Da diese Daten beim Laden des Formulars frisch ermittelt werden, nimmt das Zeit in Anspruch. Je nach Server-Auslastung vergehen genügend Ticks. → Zap-Reiz!

Eine UI-Grundregel lautet: „dauert es etwas länger, halte den Benutzer auf dem Laufenden“. Eine Armbanduhr mit drehenden Zeigern ist nicht adäquat, eine Sanduhr anachronistisch. Zugucken was passiert, daß überhaupt etwas passiert, ist besser.

Rückmeldung geben!

Die Benutzer erleben lassen, daß ihnen der Rechner Arbeit abnimmt: (1) Anfang – (2) Zwischenstand – (3) Ergebnis.

(1) das Formular wird geöffnet und stellt (2) die sofort verfügbaren Daten dar. Das sind die Feldinhalte und die Liste der Teilnehmer. Das ist nicht viel Rechnerei — Suchen und Arrays aus einer Auswahl erzeugen. 4D macht das in 0,nix.

Die Kreuztabelle zusammenzustellen ist mehr Arbeit. Suchen, Arrays erzeugen und mehrere Schleifen * durchlaufen, um die Tabellen zu füllen. Ist die Kreuztabelle fertig, wird das Formular erneut gezeichnet (3).

Aus einem langen Wimpernschlag werden zwei kurze. 4D ist wirklich schnell. → kein Zap-Reiz.

Ich will das Formular-Flackern nicht wiederhaben

4D ist smart und optimiert Formular-Flackern weg. Jede Aktion, die in einem Formular angestoßen wird und in einer Methode – im Formular oder extern – abläuft, muß zu ihrem Ende kommen. Erst dann wird das Formular aktualisiert, d.h. die Änderungen sind erst dann zu sehen. Das ist gut so! Das ist eine Optimierung, die, solange der 4D-Entwickler es nicht verinnerlicht, im Debugger verwundert oder verwirrt. Wieso verwirren? Ich denke an das boolsche Array mit dem Listbox-Namen, das erst am Ende der Methode den tatsächlichen Auswahlzustand repräsentiert [Count in array (lb_Objekt;True)].

Will ich die Optimierung ausnahmsweise nicht, weil ich dem Anwender zeigen sollte was passiert, muß ich mir einen Workaround ausdenken. Ziel ist die zeitaufwändigeren Aktionen auszulagern und nachzuziehen, um den Formular-Aufbau möglichst schnell zu Ende zu bringen und das Formular je nach Auswertestand zwei- dreimal neuzuzeichnen. In letzter Zeit habe ich Lösungen kennengelernt, die mit On Timer dieses Ziel erreichen.

On Timer ist ein Trick, Unerwünschtes mit schierer Hardware-Power zu kompensieren. On Timer hört sich im Briefing so an:

• „lauf schon mal los“ = SET TIMER (10)
• „ich sag Dir gleich was Du tun sollst“ = vt_What:="TueDies+Das"
• „Bist Du fertig mit der Aufgabe, bleibst Du wieder stehen“ = SET TIMER (0)
• „und vergißt, was Du tun solltest“ = vt_what:=""

Der Trick: die Formular-Methode kommt schnell zum Ende, 4D kann alles aktualisieren. Nach wenigen Ticks wird die Methode erneut durchlaufen, diesmal im On Timer-Event. Erreicht wird damit, die Aktualisierung aufzuteilen. Zweimal durchlaufen, bedeutet nicht doppelten Aufwand, sondern den Gesamtaufwand in zwei Teilen abarbeiten. Das ist nur wenig mehr, aktuelle Rechner schaffen das – locker.

Andere Idee

Ich schicke mir selber eine Nachricht. Die Nachrichten-Variable wird wie in On Timer über SET PROCESS VARIABLE mit einer Aufgaben-Beschreibung gefüllt. Danach rufe ich mich selbst auf mit CALL PROCESS(Current process) und handle die Aufgabe in On Outside Call ab.

Klappt! On Timer und CALL PROCESS sind Verfahren mit gleichwertigem Ergebnis. Mit CALL PROCESS sich selber aufrufen, hat nicht immer den gewünschten Effekt. 4D optimiert noch smarter als clever! Ist die Berechnung nicht sehr komplex, bleibt das Formular leer, bis auch der zweite Durchlauf, die Kreuztabelle zu füllen, beendet ist. Bei aufwändigen Berechnungen ist das Ergebnis identisch zum On Timer-Verfahren. Die 3 Formular-Zustände sind deutlich zu erleben.

Noch eine Idee

Ich beauftrage einen anderen Prozess, mir die Nachricht zu schicken. Auf meinen Clients läuft sowieso ein Dienstleistungs-Prozess. Ich schicke diesem die Aufgabe und lasse von dort die Formularmethode zurückrufen.

Das klappt auch! (1) und (2) werden angezeigt ehe (3) steht.

Das CALL PROCESS-Verfahren hat den Vorteil, nicht auf diese eine Methode beschränkt zu sein. Ändern sich die zugrundeliegenden Daten – also die Veranstaltungen oder deren Ergebnisse – an anderer Stelle, reicht es, die gleiche Nachricht von dort zu verschicken. Die angezeigte Kreuztabelle wird aus der Ferne auf dem Laufenden gehalten.

Und nun?

Sowohl als auch – ich setze beides ein. In der On Load über SET TIMER und aus anderen Bereichen der Datenbank über CALL PROCESS. Der Benutzer erlebt, wieviel Arbeit der Rechner an seiner statt erledigt.

Das sind genug Fliegen mit einer Klappe.

* eine Schleife extra, denn die Gestaltung einer Listbox (Spaltenbreiten, Farben) darf erst nach Füllung der Listbox (INSERT LISTBOX COLUMN) erfolgen. Dann klappt es trotz Cleverness. ↵

4D Themen: Berichte in Arbeit