Event exiting für Feldprüfung

[vgriesinger]

Hallo zusammen,

ich mache eine Überprüfung eines Feldes mit Hilfe des exiting-Events. Dabei überprüfe ich, ob ein Wert eingegeben wird. Wenn nicht, kommt eine Messagebox, die den Benutzer darauf hinweist. Jetzt würde ich gerne den Cursor wieder in das Feld setzen, doch alle Versuche schlagen fehl.
Hat jemand eine Idee??

Thanks,
Volker

[koehlerbv]

Du brauchst nichts weiter, als ein NotesUIDocument.GotoField ("DeinFeldWasGeradeFalschVerlassenWurde").

Das war es schon.

Bernhard

[vgriesinger]

Hallo Bernhard,
das hab ich auch gedacht, aber das hat nicht funktioniert. Hab auch nextfield oder prevfield probiert, aber irgendwie greift das nicht....

hhhmmmm, ein bug

Volker

[koehlerbv]

Next und Previous bringt ja auch nix, da ja vollkommen unbekannt ist, wohin der User "hüpft". Naja, nicht ganz unbekannt: NotesUIDocument.CurrentField sagt's ja an. Nützt aber nix  )

Hast Du das schon mal probiert:

Code

Sub Exiting(Source As Field)
	Dim ws As New NotesUIWorkspace
	Dim uidoc As NotesUIDocument
	
	Set uidoc = ws.CurrentDocument
	If uidoc.Document.Field1 (0) <> "blabla" Then
		Messagebox "Sie müssen hier 'blabla' eingeben !"
		Call uidoc.GotoField ("Field1")
	End If
	
End Sub

Bernhard

[vgriesinger]

Hallo Bernhard,

so funktioniert's dann doch, danke nochmal,

Gruß Volker

[TMC]

Volker, nur aus Interesse:

Warum machst Du die Feldvalidierung über's Exiting - Event und nicht über die Standard-Feldvalidierung, die je nach @Formel z.B. beim Refresh(F9) oder beim Speichern zuschlägt?

[Glombi]

Das Exiting Event ist für Validierungen gemeinhin unbrauchbar, denn der Cursor muss ja im Feld gewesen sein.
Es macht nur dann Sinn, wenn der User danach in ein anderes Feld geht - aber keinen Button/Action Button klickt.

Andreas

[TMC]

Genau deswegen würde mich der Grund von Volker interessieren, Andreas 
Außerdem kann dies auch den Benutzer sehr nerven, wenn dieser in Ruhe ein Dok ausfüllen will und es beim Feld-wechseln ständig "Popups" hagelt.

[vgriesinger]

hi,
also der Grund ist folgender:

Das ganze Formular besteht aus ungefähr 60 Felder, verteilt innerhalb einer Tabelle auf 4 Tabs, wobei bei 40 davon eine Prüfung stattfinden soll. Um den Anwender nun nicht erst ganz am Schluss darauf hinzuweisen, das er noch 30 Felder ausfüllen muß, die auch noch auf 4 Tabs verteilt sind, haben wir uns für diesen Weg entschieden, auch auf die Gefahr hin, das er mit dem Cursor zumindest alle Felder durchgehen muß.....

Ist sicherlich nicht die schönste Lösung, aber mir viel keine bessere Lösung ein....

[Glombi]

Das würde ich anders lösen: Beim Wechsel des Tabs erst die Validierung.
Was machst Du denn, wenn der Cursor gar nicht in einem der Felder war.

Ist es nicht besser, die Mussfelder farblich oder sonstwie zu kennzeichnen?

Andreas

[TMC]

Gut, mit 60 Feldern hätte ich jetzt nicht gerechnet 

Ich würde es trotzdem offener halten. Du könntest alternativ z.B. die Pflichtfelder entsprechend kennzeichnen, so dass Der Anwender auf 1 Blick sieht, was ein Pflichtfeld ist und was nicht.

*edit* sehe gerade dass Andreas schneller war.

[koehlerbv]

Man kann auch das eine tun, ohne das andere zu lassen. Auf jeden Fall reicht aber eine Feldvalidierung nur auf Grund des Exiting-Events nicht aus: Wie schon erwähnt, kann das unterlaufen werden.

Ich selbst finde es bei einer grossen Zah lvon Feldern aber auch besser, u.U. sofort auf eine Fehleingabe hingewiesen zu werden, als dass erst ganz zum Schluss die ganzen Fehlermeldungen aufpoppen.

Bernhard

[Glombi]

Zwischen Fehleingabe und Musseingabe sollte noch unterschieden werden.

Und es gibt nach wie vor das Problem: Wenn der geneigte Anwender direkt auf einen evtll vorhanden Speichern & Schließen Button klickt, wird das Exiting Event nicht ausgeführt!

Andreas

[koehlerbv]

Was ich gerade erwähnt hatte ...

[Glombi]

Das sind wir uns ja wieder einig 

Andreas

[TMC]

Ich selbst finde es bei einer grossen Zah lvon Feldern aber auch besser, u.U. sofort auf eine Fehleingabe hingewiesen zu werden, als dass erst ganz zum Schluss die ganzen Fehlermeldungen aufpoppen.

Das ist bei der Standard - Inputvalidiation genau 1 Meldung (und nicht mehrere), nämlich für das 1. Feld (oben links), bei dem die Validation = False ist.
Alternativ könnte man natürlich auch was z.B. über Querysave machen um in 1 Msgbox alle ungültigen Felder zu listen, das macht das ganze aber bei vielen Feldern wohl auch nicht übersichtlich.

Weitere Möglichkeiten die mir spontan einfallen:
 - wie im Web gewohnt ein (Hide-When) - Bereich in der Maske, der nach dem Save oder Refresh die Felder listet die noch nicht ausgefüllt sind
 - mit HideWhen & Tabellenzellen rot und fett markiert direkt neben den Feldern darauf hinweisen dass da noch was rein muss (zusätzlich zu den normalen Pflichtfeldmarkierungen) - das angezeigt wird wenn der User versuchte zu speichern

Matthias

[koehlerbv]

Das ist bei der Standard - Inputvalidiation genau 1 Meldung (und nicht mehrere), nämlich für das 1. Feld (oben links), bei dem die Validation = False ist.

Jo, logisch. Und dann versucht der User wieder zu speicheln, und dann kommt die nächste Meldung und darauf wiederum die nächste usw. ... Das kann dann auch nerven.

Bernhard

[Glombi]

Ich bleibe dabei: Das Exiting Event ist für Validierung gemeinhin unbrauchbar, da es NICHT in jedem Fall ausgeführt wird. Also muss man intelligenterweise die Validierung auch woanders machen.
Es bietet sich bspw. das QuerySave an - dort eine Liste der noch nicht ausgefüllten Mussfelder.

Andreas

[MartinG]

@Volker - hoffentlich kommt die Anwendung auch zum Einsatz. Bei 40 Pflichtfelder pro Maske würden meine User glaube ich alle in Streik treten....

[koehlerbv]

@Glombi: Wie ich schon sagte - man kann das eine tun, darf das andere aber nicht lassen.

@Martin: Wir wissen zu wenig über Volkers Anwendung ... Also ist da erstmal Vorsicht geboten.

Bernhard