03.07.2007, 15:14
Wenn es denn sein muss, würde ich das VI "Nach Wert durchsuchen" verwenden. Das VI hat außer dem Zahlenausgang einen Stringausgang. Dort kommt der unverdauliche Rest heraus, der sich nicht konvertieren ließ. War die Konvertierung erfolgreich, dann ist es ein Leerstring.
Zum VI: Bei erfolgreicher Konvertierung wird das originale Stringelement unverändert in die Tabelle zurückgeschrieben. Bei nicht erfolgreicher Konvertierung wird "falsch!" in das Tabellenelement zurückgeschrieben.
(Selbstverständlich wir man in der Endfassung den Case "Test" durch einen Ereigniscase "Tabelle, Wertänderung" ersetzen, und statt der "falsch!"-Meldung im Element selbst sollte man besser eine POPUP-Warnung bringen und lieber den Tastaturfokus zwecks leichter Editierung auf die fehlerhafte Eingabe setzen usw. usf.)
Da es die Möglichkeit des direkten Konvertierungstests gibt, mit sofortiger JA/Nein - Antwort, sehe ich überhaupt nicht ein, warum man statt dessen die Stringsyntax mit ihren unzähligen richtigen und falschen Möglichkeit akribisch prüfen sollte.
[attachment=7253]
Zum VI: Bei erfolgreicher Konvertierung wird das originale Stringelement unverändert in die Tabelle zurückgeschrieben. Bei nicht erfolgreicher Konvertierung wird "falsch!" in das Tabellenelement zurückgeschrieben.
(Selbstverständlich wir man in der Endfassung den Case "Test" durch einen Ereigniscase "Tabelle, Wertänderung" ersetzen, und statt der "falsch!"-Meldung im Element selbst sollte man besser eine POPUP-Warnung bringen und lieber den Tastaturfokus zwecks leichter Editierung auf die fehlerhafte Eingabe setzen usw. usf.)
Da es die Möglichkeit des direkten Konvertierungstests gibt, mit sofortiger JA/Nein - Antwort, sehe ich überhaupt nicht ein, warum man statt dessen die Stringsyntax mit ihren unzähligen richtigen und falschen Möglichkeit akribisch prüfen sollte.
[attachment=7253]
