Inoffizielles deutsches Xbase-Forum

Hallo Zusammen,

ich brauche mal wieder eure Programmiersprachenunabhängige Schwarmintelligenz/Schwarmphilosophie.

Problemstellung
Stellt euch einmal einen umfangreichen Eingabedialog vor. Auf diesem Dialog habt ihr Pflichtfelder, aber auch Kann-Eingabefelder. Wie stellt ihr sicher, dass valide Inhalte in den Felder eingetragen sind und auch Plausibilitäten eingehalten werden (numerische Eingabe, keine Character)?

Da mir in der Clipper-Welt die Picture-Klauseln für mich nicht ausreichend waren, habe ich eine eigene Eingaberoutine hinter jedes Eingabefeld gelegt und konnte so auf wirklich alles reagieren. Und ein Stück weit, ist ein Teil meines Kopfes noch mit dieser Zeit verhaftet. Wobei es damals, durch die doch eindimensionale Programmierung sehr leicht war, da ein Dialog komplett abgearbeitet werden musste, bevor man sich anderen Programmbereichen zuwenden konnte.

Unter Windows habe ich ja unzählige Möglichkeiten mehr. Was da alles möglich ist, brauch ich ja Keinem zu sagen.
Mich würde also interessieren, wie ihr auf Eingabefehler in Felder reagiert. Reagiert ihr erst beim Drücken des Button Speichern oder reagiert ihr sofort bei Verlassen bzw. bei Eintritt in ein Eingabefeld? Oder sagt ihr sogar, der Anwender ist für seine Daten selbst verantwortlich und prüft nichts.

Ich danke euch schon einmal vorab!

Beste Grüße, Dieter

P.S. Warum frage ich das erst jetzt? Ich beschäftige mich schon eine ganze Weile mit dem Thema und bin jetzt erst auf die Idee gekommen, euch zu fragen

das ist doch lediglich eine frage der gwünschten und erforderlichen funktionalität einer applikation...
ob und wie man validiert hängt eben vom gewünschten resultat bzw. derr folgewirkungen eines feldinhaltes ab...
mal so, mal so, mal so und nochmal mal so...

und validieren bedeuted keineswegs lediglich nur einen fehler abzufangen ...

Ich würde (der Einfachheit halber) erst beim speichern prüfen. Bis dahin kann man beliebig die Einträge ändern.
Unabhängig davon könnte man bei einzelnen Feldern (sofern sinnvoll) auch Einschränkungen im Vorfeld vornehmen - also numerische z.B. mit einem SpinButton versehen oder DropDowns verwenden, wenn nur bestimmte Möglichkeiten der Eingabe vorgesehen sind.

Viele Grüße,
Martin

Hallo, Dieter -


das hängt aus meiner Sicht von der jeweiligen Situation ab.

Ich habe Programme-Dialoge, in denen z.B. von der Eingabe in einem XbpSLE abhängig eine ListBox gefüllt wird. Die Einträge der ListBox hängen von der Eingabe im XbpSLE ab, also validiere ich die Werte beim Verlassen (killInputFocus)

Hallo, Dieter.

Mit der Zusatzbibliothek eXpress++ von Roger Donnay kannst Du den Clipper-Ansatz direkt und nahtlos in die Windowswelt übertragen, und Du lernst ganz nebenbei einiges über Objektmanagement, Eventhandling usw. Allerdings ist das mittelfristig auch schon wieder outdated, denn die aktuellen UIs basieren auf ganz anderem Zeug.

www.donnay-software.com - reines Xbase++

Schau dir doch mal das Beispiel von Alaska an:

c:\alaska2\source\samples\solution\xbpget

Das bringt dir die Möglichkeiten wie du Sie von Clipper in einem Get kanntest. Es kann auch alle Datentypen und Pictures .....

Schau Dir eXpress++ an, da kannst Du sowas machen:
Erzeugt GUI-Dialoge aus Statics und SLEs und was auch immer, aber mit Clipper-Syntax. Schnelle Ergebnisse, robust, leicht verständlich.

Guten Morgen Zusammen,

wow, so viele Antworten und das am Sonntag.

Zunächst einmal vielen Dank für die Mühe, die ihr euch gemacht habt.

Vielleicht nochmal zur Erklärung:
Mir geht es weniger darum, eine alte Clipper-Vorgehensweise in ein neues Kleid zu stecken, sondern darum, wie ihr eben mit Daten in Eingabefeldern umgeht. Die ein oder andere Idee war ja dabei. Ich muss mich einfach festlegen.

Ich Danke euch.

Gruß, Dieter

Hallo Dieter !

... wie ihr eben mit Daten in Eingabefeldern umgeht.

Bei einzelnen Feldern ohne Zusammenhang mit anderen, wird beim Verlassen auf Gültigkeit geprüft.
Wenn fehlgeschlagen, wird der Grund mitgeteilt und das Feld z.T. geleert und wieder aktiviert.
Bei einem Zusammenhang einzelner Felder wird beim Speichern geprüft.
Wenn fehlgeschlagen, werden der/die Gründe in einer Meldung (gegebenenfalls kummuliert) mitgeteilt und das erste Feld in der Tab-Reihenfolge wieder aktiviert.

HaPe hat geschrieben: ↑Mo, 17. Mai 2021 8:19
Wenn fehlgeschlagen, werden der/die Gründe in einer Meldung (gegebenenfalls kummuliert) mitgeteilt und das erste Feld in der Tab-Reihenfolge wieder aktiviert.

Hallo Hans-Peter,

ich Danke Dir!

LG, Dieter

hallo dieter,
ich würde mich da eher nicht auf eine vorgangsweise festlegen, wie du geschrieben hast.
du wirst wahrscheinlich alle varianten einbeziehen müssen bzw. sollen um eimne insgesamt passende abwicklung
zu bewerkstelligen.

HaPe hat geschrieben: ↑Mo, 17. Mai 2021 8:19 Bei einem Zusammenhang einzelner Felder wird beim Speichern geprüft.
Wenn fehlgeschlagen, werden der/die Gründe in einer Meldung (gegebenenfalls kummuliert) mitgeteilt und das erste Feld in der Tab-Reihenfolge wieder aktiviert.

insbesonders bei zusammenhängenden zwischen einzelnen feldern ist bei uns ein validieren in nahezu allen applikationen
bereits beim verlassen des feldes geradezu "zwingend" auf der tagesordnung da der wert des aktuell verlassenden feldes
sehr oft den defaultwert des nächsten bzw. oft auch den mehrer nachfolgender felder verändert.
da geht es dann primär nicht um "fehleranzeigen" sondern um datenerzeugung.
im konkreten gibt es bei uns apps, da stehen locker 20 felder in zusammenhängen und jede änderung bewirkt gegebenfalls
sogleich auch in allen anderen feldern ein solche.

wie schon in meinem vorigen posting gesagt, ist eine validierung auf die gültigkeit eines feldes gerade mal eine
simple "pflichtübung" aber die unmittelbare Folgewirkung eines Feldinhaltes bereits beim verlassen
abzuarbeiten ist nunmal die kür. den wert eines folgefeldes erst beim "eintreten" in das feld anzuzeigen macht genau 0 sinn.

aber wie auch schon gesagt, es hängt immer von der funktionalität einer app bzw. deren einzelnen abschnitte ab.
so könnte auch bei einer extrem banalen adressverwaltung durch ein promptes validieren beim verlassen des feldes "postleitzahl", das damit defintiv zusammenhängende feld "ort" bereits korrekt sichtbar befüllt werden bevor der gesamte eingabedialog gespeichert und beendet wird.
steckt jedoch keine plz-datenbank zur nachschau bereit dann wäre ( falls überhaupt ) eine semantischer check zu machen
da der ort ohnehin manuell eingegeben werden muß.

und jetzt mal die gedanken auf wirlich komplexe apps richten.... dann sollte eben alles berücksichtigt werden

Doch, es ist "best practice", sich auf eine allgemeine Vorgehensweise festzulegen und dann diese im Einzelfall ggf. zu variieren oder zu ergänzen. Die Mechanismen ähneln sich in aller Regel. Einfache Aufgaben wie Validierungen ergänzen sich zu Plausibilitätsprüfungen (die Eingabe in einem Datumsfeld ist valide, wenn ein gültiges Datum erfasst ist, aber kein Datum, das z.B. in einer CRM-Software in irgendeiner Weise Sinn hat, ist älter als Fensterkreuz mal Pi der 1.1.1900, und kein Geburtsdatum kann in der Zukunft liegen und ein Todesdatum ebensowenig*). Solche Aufgaben kann man in Klassen wunderbar abbilden und von Fall zu Fall abrufen. Das gleiche gilt für Pflichtfelder, also Felder, deren Inhalte befüllt sein müssen, was sich beim Verlassen des SLEs prüfen lässt (was wiederum scheitert, wenn das SLE nie den Fokus bekommt), sinnvollerweise aber beim Verlassen des Dialogs/Bestätigen der Eingabe geprüft wird, also im Eventhandling, das diese Aufgabe ebenfalls allgemein beherrschen kann.

Es gibt also mehrere Prüfungsklassen
- fehlende/Fehleingaben (leeres Datum, das gefüllt sein müsste, falscher Eintrag nach Typ oder Inhalt)
- Plausibilitätsprüfungen (Daten haben allgemein keinen Sinn oder im jeweiligen Kontext - all das lässt sich wunderbar allgemein in Klassen formulieren)
- Pflichterfassungen (Felder müssen grundsätzlich Inhalte haben oder in Abhängigkeit von anderen Feldern - und dann kann es noch unterschiedliche Konsequenzen geben, wie Zwangseingaben, Defaults, interne Aufgaben, die automatisch augelöst werden usw.)

All das sollte man sich überlegen, bevor man seine Dialoge und Dialogklassen baut. Oder, wenn das bereits begonnen hat, eben so allgemein wie möglich formulieren und auf keinen Fall in alle Dialoge per Copy&Paste hineinfrickeln und jeweils geringfügig anpassen. Damit erzeugt man Spaghetticode, der irre schwer zu warten und zu ergänzen ist. Um Steffen P. zu zitieren: Immer an die Zukunft denken! Wenn man eine Aufgabe zu lösen hat, sollte man im Hinterkopf haben, wie sich diese Aufgabe in Zukunft entwickeln könnte.

(* außer bei Software für Assassinen)

Also ich mache das abhängig wieviele Felder im dialog vorhanden sind. bzw. abzufragen sind.

sind es 1-2 Felder wo eine Prüfung erfolgen muss, mache ich das beim Verlassen des Feldes.

Sind es mehrere mache ich das beim Button "speichern"

Hinweise werden immer gegeben was nicht stimmt.

Tom hat geschrieben: ↑Mo, 17. Mai 2021 11:39 Doch, es ist "best practice", sich auf eine allgemeine Vorgehensweise festzulegen und dann diese im Einzelfall ggf. zu variieren oder zu ergänzen.

da wideerspreche ich dir in keinster art und weise, ebenso nicht zu deinen weiteren ausführungen.
letztendlich ist es auch nichts anderes als ich, etwas weniger detailliert und simpler formuliert zum ausdruck gebracht habe.

Dein "doch" ist daher fehl am platz, alles andere passt jedenfalls.
mein hinweis an dieter sagt auch nichts anders aus denn ich habe seine ansage "Ich muss mich einfach festlegen"
aufgrund seiner absicht, zu erfahren wie andere diese angelegheit lösen ao verstanden, dass er EINE, für ihn am
ehesten praktikable lösung finden möchte und keinen gedanken an eine variable handhabung verliert,

und daher, aber auch abgesehen davon, ist meine aussage
"ich würde mich da eher nicht auf eine vorgangsweise festlegen, wie du geschrieben hast.
du wirst wahrscheinlich alle varianten einbeziehen müssen"
jedenfalls korrekt und entspricht auch der "best practice", wenn man sich auf eine allgemeine Vorgehensweise festlegt und dann diese im Einzelfall ggf. variiert oder ergänzt.

manchmal muss man einfach dinge klarstellen, auch wenn es im nirwana verhallen sollte

hi,

ich arbeite möglichst nach dem "Table PC Validierung" Prinzip.

bei einem Table PC machen ich "keine Eingaben" sondern bekomme alles "vordefiniert"
ich kann "nur" aus "Vorgaben" wählen was ich "ohne Keyboard" machen kann.

---

das Datum hole ich mir aus dem PATEPICKER was immer korrekt ist

wenn ich als Datum 01.01.2021 wähle wäre das "korrekt" ...
aber wenn die Person am 01.01.2012 geboren wurde wäre die Eingabe trotzdem "falsch".

ein zusätzlich "Hilfe" wäre das Alter zur Kontrolle auszugeben

---

bei einer Adresse brauche ich mehrere Angaben wie PLZ (Stadt) und Strasse.
nur mit beiden Angaben kann ich überprüfen ob eine Eingabe "korrekt" ist.

---

bei der "Menge" kann ich nur überprüfen ob der Bestand dafür reicht.
ob nun 1 Stück oder 10 Stück gemeint ist kann ich nicht überprüfen

---

es kommt also aus die Art der Validierung an wo es "Sinn" macht.

Hallo Zusammen,

eine Menge Antworten und dafür nochmals meinen Dank.

Es sind auch viele Anregungen dabei. Wie so oft, habt ihr mich weitergebracht.

LG, Dieter