Domino 9 und frühere Versionen > ND7: Entwicklung

Textfeld - auf Zahleneingabe prüfen

(1/3) > >>

Demian:
Moin,moin,

ich musste heute feststellen, dass ich bei der Überprüfung auf Zahleneingabe in Script mit IsNumeric etwas auf die ... gefallen bin, weil ich die Eingabe von Hexzahlen nicht berücksichtigt habe (worauf die User auch manchmal kommen  ;D ).

Vorerst werde ich das Problem mit einer kleinen Schleife lösen:


--- Zitat ---   Dim intChar As Integer   
   Dim strTest As String
   
   strTest = Ucase("6699e33")
   
   If Isnumeric(strTest) Then
      For intChar = 65 To 90
         Print "prüfe " & Chr(intChar)
         If Instr(strTest,Chr(intChar)) > 0 Then
            Msgbox  Chr(intChar) & " enthalten"         
            Exit Sub
         End If ' Instr(strTest,Chr(intChar)) > 0
      Next intChar
   End If 'Isnumeric(strTest)
--- Ende Zitat ---
   
   
Da ich aber nicht so der Anhänger von Schleifen bin (wenn es sich vermeiden lässt), würde ich gern wissen ob es es elegantere Methoden gibt und wäre für Anhaltspunkte sehr dankbar.

Gruß
Demian


 

koehlerbv:
Hallo Demian,

zwei Fragen meinerseits:
1) Warum verwendest Du überhaupt ein Textfeld und kein numerisches?
2) Was machst Du, wenn mit 1E2 nicht eine Hexadezimalzahl = dez482 gemeint war, sondern die "Engineering-Darstellung", also 1*102 = 100? Oder doch ein Tippfehler durch Wurstfinger?

Ich befürchte, Du programmierst hier um des Pudels Kern herum  :)

Bernhard

Demian:
Moin Bernhard,

also etwas mehr zum Hintergrund.

Ein Textfeld deswegen, weil abhängig von dem gewählten "Dokument-Typ" (Optionsschaltfläche) , auch die Eingabe von Buchstabenfolgen möglich sein muss. Ich hätte es von vornherein auch über 2 oder mehr Felder, lösen können, habe mich jedoch dagegen entschieden, weil es sich hier um ein "Schnittstellenfeld" zu unserer Zeiterfassung handelt und ich mich so im Export-Agenten nur um ein Feld kümmern muss.

Wenn der betroffene Dokumenttyp gewählt ist, können nur 2-stellige, 5-stellige oder 7-stellige Nummern eingegeben werden.

Betroffen ist der 7er Teil deswegen, weil in der Datenbank auch sogenannte Chip-Zuordnungen (extra Maske) zu den Kostenträgern eingegeben werden können. Es handelt sich hier um "Buttons" mit denen auf den Baustellen die Zeit erfasst und nach dem Auslesen entsprechend dem Kostenträger zugeordnet wird. Diese Buttons haben eine Hardwareseitige Kennung, die immer 7-stellig (mit 5 führenden Nullen) aufgebaut ist (siehe Screenshot).

Manch einer verwechselt leider diese Chip-Zuordnung und gibt diese in der Maske Kostenträger als 7-stellige Kostenträgernummer ein... ::)

PS: Der Vollständigkeit halber noch ein Screenshot der Kostenträger.

Axel:

--- Zitat von: koehlerbv am 04.10.10 - 19:30:09 ---Ich befürchte, Du programmierst hier um des Pudels Kern herum  :)

--- Ende Zitat ---

Da muss ich Bernhard zu 100% recht geben.


--- Zitat von: Demian am 04.10.10 - 20:03:52 ---...habe mich jedoch dagegen entschieden, weil es sich hier um ein "Schnittstellenfeld" zu unserer Zeiterfassung handelt und ich mich so im Export-Agenten nur um ein Feld kümmern muss.

--- Ende Zitat ---

Es ist aber wesentlich einfacher und auch noch für die gesamte Anwendung performater und weniger fehlerträchtig im Export-Agent das, dem Dokumenttyp entsprechende Feld zu bearbeiten. Das ist nur eine IF oder SELECT CASE Anweisung.

So programmierst du dir einen Wolf und hast immer noch nicht alle Eventualitäten abgefangen. Und glaube mir, User können in Falscheingaben unheimlich kreativ sein.

Axel

Demian:

--- Zitat ---Es ist aber wesentlich einfacher und auch noch für die gesamte Anwendung performater und weniger fehlerträchtig im Export-Agent das, dem Dokumenttyp entsprechende Feld zu bearbeiten. Das ist nur eine IF oder SELECT CASE Anweisung
--- Ende Zitat ---

Das habe ich so im Prinzip auch, halt nur abhängig von der Optionsschaltfläche. Außerdem wäre es vielleicht eher verwirrend, da in der Schnittstellendatei, der Kostenträger auch immer an derselben Stelle steht ob jetzt Zahlen oder Buchstaben, und so der Aufbau in beiden Anwendungen gleich ist.

Es würde aber auch nichts an der Problematik ändern, wenn ich ein zusätzliches Zahlenfeld verwende, weil hier Werte wie 6699E33 eben auch eingegeben werden können und nur umgewandelt (ohne Kommas zu 6699000000000003396394276933278888463) werden, was wiederum die User nur schwer irritieren würde.



--- Zitat ---So programmierst du dir einen Wolf und hast immer noch nicht alle Eventualitäten abgefangen. Und glaube mir, User können in Falscheingaben unheimlich kreativ sein.
--- Ende Zitat ---

Das müsste eigentlich die Letzte Eventualität gewesen sein. Auch beim Zahlenfeld muss ich meine restlichen Überprüfungen drin lassen.

Und bei der DB will ich Schnittstellentechnisch nichts bis in letzte Detail programmieren, weil ich hoffe, dass diese Problematik (das Programm Zeiterfassung) vielleicht ein Ende hat (zu Bernhard zwinker).
 

Navigation

[0] Themen-Index

[#] Nächste Seite