Float Validieren mit StringRegExp

  • Da $ES_NUMBER auf einem Input keine Komma/Punkte erlaubt, war meine Idee einfach ein Standard Eingabefeld zu erstellen und dann die Validierung selbst vorzunehmen. Jetzt möchte ich Prüfen, ob die Eingabe ein Float ist. Dabei soll Komma sowie als punkt als Trennzeichen akzeptiert werden.

    Das obere auskommentierte $pattern war meine Idee für den RegEx.


    Das True/False im ConsoleWrite ist was ich als Rückgabe erwarte.

    Aktuell kriege ich für alles immer den gleichen Rückgabewert ... irgendwas passt noch nicht. Kann mir jemand aushelfen?

  • Mit etwas Suche findest Du sicher elegantere Pattern, aber hier mal q&d :

    AutoIt
    Local $sString = "-102.99"
    Local $sPattern = "(?i)^(\-?)(\d+)[\.,](\d{2})$"
    If StringRegExp($sString, $sPattern) Then
    ConsoleWrite("! StringRegExp = TRUE" & @CRLF)
    Else
    ConsoleWrite("! StringRegExp = FALSE" & @CRLF)
    EndIf

    (\-?) lässt auch ein Minus am Anfang zu.

    Einziger Haken : ein Wert wie 000,99 (also mehrere Nullen vor dem Separator würde momentan noch akzeptiert. Das kann man aber auch checken, falls es für Dich von Bedeutung ist.

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Einziger Haken : ein Wert wie 000,99 (also mehrere Nullen vor dem Separator würde momentan noch akzeptiert. Das kann man aber auch checken, falls es für Dich von Bedeutung ist.

    Mit Local $sPattern = "(?i)^(\-?)([0]|[1..9]\d*)[\.,](\d{2})$" kann man auch diesen Fall prüfen.

    Das geht wahrscheinlich schöner. aber ggf. reicht es Dir ja aus ;).

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Werd ich mir ansehen. Das Programm ist für mein Bruder. Nach ihm sei das alles egal, aber ich will schon gern alle Eingaben validiere.

    Ich werd es mir ansehen ^^

  • Mit Local $sPattern = "(?i)^(\-?)([0]|[1..9]\d*)[\.,](\d{2})$" kann man auch diesen Fall prüfen.

    (?i) ? ...ich frage dich jetzt nicht, wofür das in dem Pattern gut sein soll... aber du solltest es tun... 8o

    Das Pattern ist soweit gut... nur denke ich, dass variable Eingaben mit nur einem Pattern zu prüfen, sehr schwer bis unmöglich ist.


    So wie es in dem Thread aus dem EN-Forum gezeigt wird, kann man es natürlich machen, aber das sind alles sehr schlechte Lösungen.


    Fast schon sträflich finde ich, wenn WM_COMMAND & Co. in einer UDF verwendet werden, da diese Nachrichten somit nicht mehr ohne weiteres für eigene Fälle genutzt werden können - besser geht es z.B. mit _WinAPI_SetWindowsHookEx... siehe Bsp. in der AutoIt-Hilfe... und dort dann mit If $wParam = $WM_COMMAND prüfen.


    Anstatt $EN_CHANGE würde ich $EN_UPDATE verwenden... denn so kann die Eingabe abfangen werden, bevor sie angezeigt wird.


    $EN_CHANGE wird gesendet, wenn der Benutzer eine Aktion ausgeführt hat, durch die möglicherweise Text in einem Bearbeitungssteuerelement geändert wurde. Im Gegensatz zum $EN_UPDATE-Benachrichtigungscode wird dieser Benachrichtigungscode gesendet, nachdem das System den Bildschirm aktualisiert hat. Das übergeordnete Fenster des Bearbeitungssteuerelements empfängt diesen Benachrichtigungscode über eine WM_COMMAND-Nachricht.


    $EN_UPDATE wird gesendet, wenn sich ein Bearbeitungssteuerelement neu zeichnet. Dieser Benachrichtigungscode wird gesendet, nachdem das Steuerelement den Text formatiert hat, aber bevor der Text angezeigt wird. Auf diese Weise kann die Größe des Bearbeitungssteuerungsfensters bei Bedarf geändert werden. Das übergeordnete Fenster des Bearbeitungssteuerelements empfängt diesen Benachrichtigungscode über eine WM_COMMAND-Nachricht.


    In einem meiner Scripte habe ich so eine selbst geschriebene Funktion für spezielle Inputs eingebaut... aber heute habe ich keine Energie mehr, um danach zu suchen...

  • (?i) ? ...ich frage dich jetzt nicht, wofür das in dem Pattern gut sein soll... aber du solltest es tun... 8o

    Selbstverständlich darfst Du fragen ! ;)

    In diesem Fall ist (?i) , also die Nichtberücksichtigung von Groß-/Kleinschreibung, natürlich für gar nichts gut, da keine diesbzgl. relevanten Zeichen im Spiel sind. Ich habe diese Option wohl mehr aus Gewohnheit gesetzt. Sie frisst hier kein Brot, aber Du hast recht - man sollte Reguläre Ausdrücke nicht komplizierter machen, als sie ohnehin schon sind.

    Wieso ahnte ich bereits, dass Du auf diesen Umstand hinweisen würdest ? :P

    Das Pattern ist soweit gut...

    Danke, ich hatte mal wieder Lust ein Pattern selbst zu schreiben (nicht zu kopieren). Auf diesem Gebiet setzt man eh schnell Moos an, wenn man länger nichts macht ^^.

    ... nur denke ich, dass variable Eingaben mit nur einem Pattern zu prüfen, sehr schwer bis unmöglich ist.

    Dem stimme ich zu !

    Im vorliegenden Fall hat Yaerox seine Anforderung aber klar definiert. Soll er entscheiden, ob ihm die Lösung ausreicht.


    Der Link auf den Thread von Melba23 im EN-Forum diente lediglich als Hinweis, dass es Möglichkeiten gibt in Inputfeldern auch Punkte zu verwenden. Auf die Problematik mit WM_COMMAND & Co haben u.a. Du in der Vergangenheit bereits häufiger hingewiesen. Da auch andere User diesen Thread lesen, sind Deine Ausführungen zweifellos hilfreich.


    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Ich habe mich vorerst für:

    Code
    StringRegExp($sINPUT, '^(\d{1,7}[\.,]\d{1,2})$')

    entschieden. Das hatte ich fertig noch bevor die erste Antwort kam. Da ich noch in der ersten Phase bin und alles nacheinander aufbaue war noch keine Zeit mehr zu testen. Validierungen etc. sind grad an der Reihe und dann gibts nur noch ein paar Kleinigkeiten bevor es in den ersten CodeReview mit Details geht. Ich werde dann die RegEx nochmal vergleichen :)