Designer-Events onBlur / onFocus?

Archiv Ideen & Anregungen
1

Folgendes als Beispiel für das Problem:

zwei Text-Eingabeboxen zur Erfassung von je einem Datum („von“ und „bis“). Beide werden „onchange“ durch ein Script behandelt, um korrekte Datumseingabe sicherzustellen. Soweit ok.

Beide Werte bilden zusammen aber eine Info-Einheit (nehmen wir mal an, eine geplante Alarmpause, weil Raum mit Event belegt). Nachfolgende Aktion (Speichern des Records) darf aber erst erfolgen, wenn BEIDE Werte korrekt eingegeben vorliegen. D.h. „onChange“ an einem der beiden Werte ist noch nicht hinreichend für die Speicherung.

Ergo: Ein „Speichern“-Knopf wird zwingend notwendig, der die eigentliche Speicherung des gesamten Records auslöst. Bediener muß ja immer auch Gelegenheit haben, den 2. Wert einzugeben.

Clevererweise ist dieser Knopf nun „disabled“ (also enabled=false), solange nicht beide Datums-Überprüfungen an den Feldern ihr OK gegeben haben.

Soweit so gut und funzt auch alles. NUR:

Nun das Problem aus der Praxis im Designer:

  1. alle Bedingungen sind OK, d.h. beide Datumswerte sind korrekt, OK-Button steht aber noch auf „false“. Erst wenn ich außerhalb klicke oder per Tab weiterspringe passiert „onchange“ am letzten Inputwert.

  2. Ich stehe mit dem Cursor noch im Text-Input-Feld, (ok noch disabled), klicke dann mit der Maus sofort in den Knopf --> kein OnChange-Test!

andersrum (noch fataler):

  1. alle Werte ok, einmal außerhalb geklickt, Knopf ist freigegeben.
  2. ich gehe wieder in ein Datum und mache es z.B. leer oder Werte wieder „kaputt“ (30.2., oder 5.17.2008 oder sowas)
  3. ich klicke sofort auf den (immernoch freigegebenen) Knopf, noch war ja kein "onChange, Cursor steht noch im Input-Feld --> ER SPEICHERT DEN WERT (und testet nicht erst)

Aus der HTML / JavaScript-Welt kenne ich es, solche Sachen mit „onFocus“ (Objekt „erhält den Fokus“, also z.B. reingeklickt) bzw. „onBlur“ (Objekt verliert den Focus, z.B. weil was anderes angeklickt wird) zu behandeln. ABER onBlur wird immer noch erst „zuende ausgeführt am den Focus verlierenden Objekt“ bevor eine andere Bearbeitung an anderen Objekten beginnt (z.B. onclick am Button)

============
Wunsch: „onBlur“- / „onFocus“-Designerevent (oder irgend eine sicher nachvollziehbare Reihenfolge-Verriegelung, bevor ein anderes Objekt sein Event beginnt zu bearbeiten, insbesonders vor Button-Onclick)

Einziges Workaround bisher: An jedem Objekt zum ersten spezielle Handler, zzgl. auch noch zusammengefasst ein Script mit nochmal allen Tests hinterm Speichern-Button. Problematisch ist daran, dass das in Wahrheit nicht nur 2 Datumsfelder sind (war nur stark vereinfachtes Beispiel), sondern evtl. hochkomplexe Kombinationen von Feldern, durch Radio-Auswahl freigegebene Bereiche usw. Wirkliche Forms eben.

Auf die müßte dann ein Absenden-Test in allen möglichen Kombinationen von potentiellen Fehlern reagieren. Einzelnd am jeweils betroffenden Input-Feld ist das viel simpler machbar / z.B. mit mehreren solchen „enable-Freigaben“ vorab kombinierbar.

Ich hoffe, das ich das Problem verständlich beschreiben konnte. Betroffen dürfte jeder sein, der Input-Kombinationen ab zwei Werte in Kombination korrekt vortesten möchte, um nur inhaltlich korrekte Records gespeichert zu haben.

Gruß Gerd

2

„onBlur“- / „onFocus“

Das wäre Möglich.

ABER onBlur wird immer noch erst „zuende ausgeführt am den Focus verlierenden Objekt“ bevor eine andere Bearbeitung an anderen Objekten beginnt (z.B. onclick am Button)

Das wäre im Designer nicht realisierbar.

Warum machst du die Plausibilitätsprüfung nicht im Script, welches an den Button angeschlossen ist?

paresy

3

Grund ist die Linearisierung der sonst möglichen potenzhaft steigenden Anzahl von zu testenden Kombinationen bei unterschiedlichen Formularinhalten bzw. eben der Anzahl der dann gegenzutestenden potentiellen Fehlern.

Beispiel:

Radiobutton vorne für „per Mail“
(mit darunter dann den Parametern)

nächster Abschnitt (alternativer Radio) „per FTP“
(darunter die evtl. FTP-Parameter),

dritter Abschnitt (per Freigabe)
(darunter deren Parameter)

Bei „Verursacherprinzip“ brauch ich nur die Werte (und deren Abhängigkeiten voneinander) des aktiven Abschnittes zu testen, also da, wo das radio aktiv ist (z.B. eben nur die FTP-Parameter) Die anderen Felder werden im Gegenteil bei Radio-Aktivierung sogar disabled / leergepustet (potentielle User-Fehler-Vermeidung, z.B. „im Formular zu verrutschen“ und User/Passwort an falscher Stelle einzugeben)

Die schon bei Eingabe testbaren und auch getesteten Werte brauche ich später nicht mehr testen (z.B. „ist Input numerisch“ oder „gültiges Datum“ usw) --> Linearisierung des Aufwandes

Ich möchte (das ist der Hauptgrund) den Absendeknopf erst freigeben, wenn alles stimmt. Genau das kann ich ohne dem aber nicht, auch nicht mit zwischengeschobenem Gesamttest-Script, weil er bei „vorher war alles ok / er war freigegeben“ - dann „kaputteditieren“ - dann (Cursor steht noch im letzten (kaputteditierenden) Textinput: "Direkter Klick auf (noch freigegebenes) ‚Absenden‘ " immer sofort final speichert / ich keine Möglichkeit habe, dazwischen noch zu testen. --> Nach OK ist Eingabemaske weg (Vermeidung doppeltes „Neu“ Speichern gleicher Werte-Records) --> Ergo: Alle korrekten Inputs weg, komme ja nicht „zurück zur Maske mit allen Werten“

Es geht ja schon um den finalen Test. Nur der ist so wie es ist, immer umgehbar / doch korrupte Werte speicherbar

War auch nur so eine Idee, kenn das so vom HTML / JavaScript her. Sicher gehts alles auch ganz anders zu machen (Assistenten-ähnliche einzel-Formulare), nur dann eben mehr Schritte nötig für Bediener

Gruß Gerd