Office: (Office 2016) leeres Textfeld prüfen

Guten Morgen @all

ich hätte eine Verständnis Frage zur Prüfung leerer Textfelder.

Ich prüfe per Ribbon Button beim Speichern ob bestimmte Textfelder einer Adresse ausgefüllt wurden.

Mit dieser Anweisung erfolgt die Textfeld Prüfung nicht:
If IsNull(Forms!frmAdr!txtTelefon) Then MsgBox "Bitte Telefon-Nr. eingeben"

Mit dieser Anweisung erfolgt die Textfeld Prüfung:
If Trim(Nz(Forms!frmAdr!txtTelefon "")) = "" Then MsgBox "Bitte Telefon-Nr. eingeben"

Ich würde gerne wissen und verstehen warum die Prüfung mit IsNull(Forms!frmAdr!txtTelefon) nicht funktioniert.

Danke

:)

 

Ich fürchte, da musst du die fragen, die das Control programmiert haben.
Jedenfalls fällt das in der Bereich Bug.

Kürzlich hatte ich das Problem, dass in der Entwicklerversion die Prüfung auf IsNull (bei einer Combobox) klappte, dann in der Runtime nicht mehr.

Das Trim ist bei mir allerdings nicht erforderlich.

 

\@markusxy

Danke für den Hinweis das es sich um einen Bug handeln muss.

Kurioserweise funktioniert bei mir die IsNull Prüfung der Textfelder bei einer Neuanlage und Sichern einwandfrei, allerdings nicht beim nachträglichen Bearbeiten und Sichern. Ist mir dadurch auch eher zufällig aufgefallen.

 

Vorrangig sollte man verstehen, dass die zweite Anweisung auf einen Nullstring prüft, im Unterschied der Prüfung auf NULL in der ersten Anweisung.

Zweites nötiges Grundverständnis: NULL ist etwas anderes als ein Nullstring. Es ist das Unbekannte, Undefinierte, Nichtfassbare, und somit ein anderer Zustand als (schon mal) ein String ohne enthaltene Zeichen.

Die Verwendung von Trim (Beseitigen der äußeren Leerzeichen) beinhaltet schon die Erwartung, dass da etwas ist, über nichts hinaus.

 

\@ebs17,
jetzt musst du das nur noch dem Steuerelement erklären.

Vielleicht funktioniert es danach auch richtig. *grins

 

Der Inhalt des Steuerelementes hat eine Vorgeschichte. Wenn man die nicht kennt, ist es unangemessen, pauschal von einem Bug zu sprechen, es sei denn, man bezieht den Entwickler von dessen Verwendung ausdrücklich mit ein.

 

\@ebs17

danke für deine Erläuterungen betreffs Prüfung auf NULL und Nullstring.

Da es aber keine Vorgesichte der zu prüfenden leeren Textfelder gibt
bleibt die Frage warum die Prüfung mit IsNull nicht immer funktioniert.

Wie von @markusxy geschildert hat er ein ähnliches Problem wenn die IsNull Prüfung in der Entwicklerversion funktioniert und in der Runtime nicht.

 

Eine Textbox ohne Vorgeschichte ist irgendwo eine Klasse in den Tiefen der Accessprogrammierung. Prüfen kannst Du nur Instanzen davon, die somit initialisiert werden mussten.

 

Ich habs jetzt kurz in meiner Anwendung überprüft.

In der Runtime ist der Datentyp Empty in Access Null.
Auch wenn man den Inhalt aus dem Control löscht wird er in der Runtime zu Empty

Prüf mal in der Anwendung den Inhalt des Controls auf vartype, oder Typname.
Dann wird der Datentyp der Variant Variable angezeigt.

In meinem Fall könnte ich also prüfen vartype(control.Value) < 2

 

Als Praktiker, dem das Wie und Warum des Leerseins egal ist, könnte man auch prüfen:
Code:

Ob man da zusätzlich Trim benötigt, um Blanks (die ohne Grund vom Himmel fallen) außenherum zu beseitigen, mag man dann selbst beurteilen.

 

Hallo,

das es sich um einen Bug handeln soll, mag ich ohne weitere Belege nicht nachvollziehen. Ich habe noch nie mitbekommen, daß eine Access.Textbox den Wert Empty annimmt. Entweder sie hat eine Inhalt, dann ist sie nicht NULL oder Access setz den Wert auf NULL zurück, wenn der Inhalt gelöscht wird. Dieses Verhalten kann durch die Bindung an ein Recordsetfeld, durch Formate oder Defaultwerte beeinflußt werden, aber Empty war zumindest bei mir noch nie dabei.

In einem anderen Forum ist dieser Ausdruck zur Prüfung verwendet worden:
Code:

wobei trim() entfallen könnten, wenn man nur auf NULL/Leerstring und nicht auch auf "String mit Leerzeichen"/NULL/Leerstring prüfen möchte. Damit sollte die Prüfung sicher gelingen.
http://www.office-loesung.de/p/viewt...Empty#p3252378

@markusxy:
Deine Aussage:

ist irgendwie widersprüchlich. Könntest du mal ein Beispiel hochladen? Welche Access Version, welche BE?

Gruß Ulrich

 

\@ebs17
Danke für deine Lösung für Praktiker!
Das wie und warum des Leerseins ist mir dennoch nicht egal
sonst hätte ich die Frage nicht gestellt...

@knobbi38
Danke für deinen Prüfvorschlag wird auch getestet.

 

=> Wenn korrekte Angaben bei Eingabe nicht zwingend vorliegen müssen, ist es systematisch falsch, das Feld als Pflichtfeld zu installieren. Da kann doch nur Mist kommen.

=> Wenn man schon die User dazu erzogen hat, irgendwas statt korrekte Informationen einzugeben, sollte das vielleicht besser geprüft werden.
Eine Eingabe von 0123 wäre nach Deiner Prüfung korrekt, moritz auch, eine Erotikhotline ganz lustig. In der Praxis aber unbrauchbar und eher schädlich: Bei einem Leer wüsste man, dass man den Inhalt nicht verwenden kann, sowie auch, dass man da nachfragen müsste.

Nach einem Neuöffnen des Formulars hätte man durch gegebene Einstellungen definierte Zustände in solch einer Textbox. Nach Benutzereingaben, die keiner kennt, kann dann auch völlig anderes vorliegen.

Der Begriff "Ähnlichkeit" kann da schon Heiterkeit verbreiten.

 

\@ebs17
If Len(Forms!frmAdr!txtTelefon & vbNullString) = 0 Then

Prüfung erfolgt zuverlässig (ohne Trim)!


@knobbi38
If (Nz(Forms!frmAdr!txtTelefon)) = Empty Then

Prüfung erfolgt zuverlässig (ohne Trim)!


Danke für die Vorschläge und Erläuterungen

 

\@ebs17
Heiterkeit egal wodurch erzeugt ist doch durchaus positiv zu bewerten!

Prinzipiell bin ich natürlich bei dir und dennoch zeigt die Praxis das
es immer wieder Ausnahmen gibt das der Anwender einen Datensatz
schnell anlegen muss auch wenn er nicht alle normalerweise notwendigen
Angaben zur Verfügung hat. Dann kann er gewollt auch "Erotikhotline"
eingeben, aber wir haben uns auf "ab123" geeinigt wenn keine korrekten
Angaben vorhanden sind...