Gefährlicher Automatismus

Um genau zu sein : Aus 10.00 wird 1.000,00 .
Und aus 10.000.0 wird 100.000,00 .

D.h. der Parser entfernt zunächst alle Punkte aus der Eingabe und faßt die Zahl dann (falls sie kein Komma enthält)
als Ganze-Euro-Eingabe ohne Nachkommastellen auf.
Dann wird sie wiederum "voll formatiert" angezeigt (mit 1.000er-Punkten und Komma/2 Nachkommastellen).

Das ist in der Tat gefährlich !
Ich würde deshalb empfehlen :
Auch den Punkt wie andere Nichtziffern-Zeichen als ungültige Eingabe werten (Ausrufezeichen bleibt neben dem Eingabefeld).
D.h. es werden bei Deutscher Tastaturbelegung nur Ziffern und das Komma als gültig akzeptiert.
(Und die "Rechenzeichen" für Eingabeberechnungen.)

Keine Extra-Meldung => Ausrufezeichen bleibt neben dem Eingabefeld (= ungültiger/unklarer Betrag).

Hallo Klaus,
(mehrfaches edit erschwert das Zitieren )

es gibt 3 Möglichkeiten :
1) Nichts ändern (10.00-Falscheingeber ist selbst schuld).
2) Schnelle Abhilfe = keine Punkteingabe mehr möglich.
3) Anspruchsvolle Parser-Programmierung : 1.234,56 ist gültig, 12.34 nicht.


Wobei man sagen könnte, bei Excel darf man erstmal alles mögliche, bei B4W dagegen ist das Geld weg ... :roll:

Ohne weitere Aufregung würde ich sagen :
Ein 10.00 darf man ohne Brille übersehen, ein 1000000 eher nicht so sehr.
Formal (deutsche Notation) ist halt die Eingabe 10.00 "unklar"/ungültig, 1000000 dagegen nicht.
Insofern hat Wolf Bartels mein Verständnis - und die Variante 3) wäre natürlich mein Favorit.

Gruß
Maxl

PS: Statt eines irritierenden Ausrufezeichens ... - das Ausrufezeichen ist schon am Anfang im UW-Formular ...

@Maxl:
So richtig kann ich Dir da immer noch nicht folgen. Wieso ist

1.234,56 gültig und 12.34 nicht?

Selbstverständlich wären das 12,34 € - aus dem Punkt wird schlicht ein Komma und nichts brennt an....

Mir gehts im Vergleich zu Excel auch eher um die mittlerweile etablierten Standards in der Bedienung von "Technik", nicht darum, ob ein Excel-Blatt erstmal nur rumliegt oder B4W sofort bei der Bank anklopft.
Zu Zeiten der 386er PCs gabs Tastaturtreiber, die "Punkte" in "Kommata" oder vice versa gewandelt haben. Und das auch, um Excel-Fehlbedienungen abzufangen. So etwas lässt sich heute noch einfacher nachbilden, dürfte aber auch keine 100%ige Sicherheit gegenüber Unaufmerksamkeit des Hauptproblems (nämlich zwischen Stuhllehne und Monitor) bieten............


Klaus

In Hibiscus hab ich das so geloest:

a) wenn ein Komma angegeben ist, gilt das

b) wenn sowohl Punkte als auch Komma vorhanden sind, werden die Punkte ignoriert, weil die dann nur Tausender-Trenner sind, die zum Parsen nicht relevant sind.

c) ein Punkt wird nur in einem einzigen Fall interpretiert: Wenn der Text keine Kommas (sondern nur Punkt) enthaelt und sich dieser Punkt an drittletzter Stelle (also z.Bsp. 100.00) befindet. Dann wird er als Komma interpretiert - sonst ebenfalls ignoriert.

Klaus,
beruhige Dich doch bitte, Du hast da offenbar etwas mißverstanden.
Keiner will "gelbe Ausrufezeichen an den Rand malen".
Siehst Du denn die Warndreiecke nicht, die im UW-Formular rechts von den zu belegenden Feldern stehen ?
Darin ist ein Ausrufezeichen (jedenfalls bei mir) und um die geht's.

Bitte gib dort mal als Betrag "a12" ein.
Dann sagt das Info-Warndreieck bei Mouse-Over "Ungültiger Betrag oder Ausdruck!".


Und nun zurück zu den Betragszahlen.
Es geht - nachdem was Andreas geschrieben hat - schlicht um Folgendes :
Wie kann man, unter Beibehaltung des .NET-Parsers, der die Punkte im Betrag schlicht ignoriert, verhindern,
daß hinten etwas rauskommt, was der Benutzer so definitiv nicht eingeben wollte ?

Also nicht die Frage : Mache ich aus 12.34 ein 12,34 ?
Sondern : Im Moment wird aus 12.34 ein 1.234,00, und das war sicher nicht gewünscht !
Also muß ich vor dem Parsen die 12.34 als ungültig ablehnen (nämlich so wie bei "a12").
Dann kann der Benutzer nicht einfach das falsche Eingabe-Resultat übersehen/ignorieren und im Auftrag weitermachen.

So. Alles weitere an Schönheit erforderte einen intelligenteren Parser.
Aber wir wollten ja für Wolf Bartels und alle Anderen erstmal nur das Schlimmste verhindern.
Was mit einer RegEx-Prüfung vor dem Parsen - wie von Andreas vorgeschlagen - auch sicher funktioniert.

Grüße
Maxl

Hallo Klaus,
so wie Du mich zitierst

nimmst Du die Vorgaben von Andreas/Subsembly dazu nicht zur Kenntnis :



Davon abgesehen wären wir aber auch bei einem anderen Parser leider völlig verschiedener Meinung :
Ich möchte keinesfalls eine Software, die aus meiner Eingabe "z52" im Hintergrund diensteifrig ein "52,00" macht, ohne dabei zu murren !
Denn gemeint war 752 (Taste Z neben der 7).

Aber das steht so ja auch im Moment nicht zur Debatte.

Deshalb jetzt erstmal eine gute Nacht
Maxl

Das Problem ist doch, dass Punkt und Komma in Deutschland und Amerika genau vertauschte Bedeutungen haben:

In Deutschland: 1.234,56
In Amerika: 1,234.56

Wenn man den Betrag manuell per Tastatur eingibt (also Zeichen für Zeichen), könnte man vom Anwender verlangen, die "richtigen" Zeichen einzugeben (z.B. je nach Ländereinstellung).

Es ist aber doch ganz praktisch, neben Kontonummern auch Beträge aus E-Mail-Rechnungen oder PDFs rauszukopieren. Und da kommt es eben vor, dass selbst deutsche Händler amerikanische Software verwenden und Punkt und Komma vertauschen.

An sich ist es doch ganz einfach an der Position des Zeichens auszumachen, zumindest hier: Denn Euro-Beträge haben maximal zwei Nachkommastellen, Tausendertrenner kommen nur alle drei Stellen (von links gezählt) vor. Damit kann man eindeutig erkennen, ob es sich um deutsche oder amerikanische Trennzeichen handelt.

Also:

1,23 => deutsche Schreibweise für 1 EUR 23 Cent
1.23 => amerikanische Schreibweise für 1 EUR 23 Cent

1,234 => amerikanische Schreibweise für 1.234 EUR 00 Cent
1.234 => deutsche Schreibweise für 1.234 EUR 00 Cent

1.234,56 => deutsche Schreibweise für 1.234 EUR 56 Cent
1,234.56 => amerikanischeSchreibweise für 1.234 EUR 56 Cent

1.234.56 => Fehler (zweimal der gleiche Trenner)
1,234,56 => Fehler (zweimal der gleiche Trenner)

1.234.567 => deutsche Schreibweise für 1.234.567 EUR
1,234,567 => amerikanische Schreibweise für 1.234.567 EUR

1.234,567 => Fehler (unterschiedliche Trenner, aber 3 Nachkommastellen)
1,234.567 => Fehler (unterschiedliche Trenner, aber 3 Nachkommastellen)

Wobei hier könnte man sich noch drüber streiten:
1,2 => Ist das ein Fehler oder sind 1 EUR 20 Cent gemeint?
1.2 => Ist das ein Fehler oder sind 1 EUR 20 Cent gemeint?


Was ich jedenfalls für riskant halte, ist, dass eingegebene Zeichen, weil sie nicht passen, einfach weggelassen werden (also aus "10.00" einfach "1000" machen). Das gilt auch für sonstige Zeichen (siehe Beispiel mit z52), außer dass man "€", "EUR" und "EURO" (caseinsensitive) erkennen darf (wobei man dann - wenn man's ganz genau nehmen will, auch "3 EUR 20" als "3,20" erkennen müsste). Entweder wendet man eine eindeutige Regel an (hier: amerikanischen Dezimalpunkt erkennen (aufgrund von zwei Nachkommastellen) und in deutsches Dezimalkomma wandeln) oder man warnt den Benutzer, dass die Eingabe "10.00" falsch ist (denn 1000 EUR wäre korrekt "1.000" und nicht "10.00").

Das wäre halt mein Vorschlag. Und um ganz sicher zu gehen, würde ich eine Programmeinstellung "Ländereinstellung/Dezimaltrennzeichen" anbieten: deutsch (Komma) oder amerikanisch (Punkt) oder automatisch (Erkennung anhand der Position der Trennzeichen), wobei per Standard deutsch aktiv ist und beim ändern auf "automatisch" dann eine Warnung kommt, die auf die Problematik hinweist.

Ich denke, wenn ich mir den Kundenkreis von B4x betrachte, sollte man nicht so "gnadenlos" sein,
sondern wie gewohnt eher behilflich, wenn es doch einfach möglich ist.


Eine stringente Linie muß im Programm sein !


@Andreas
Bitte pflanz doch die RegEx rein, dann wäre der Thread hilfreich beendet.