Office: (Office 2013) Fehler 6

Hallo Forum,

es geht um den sinnvollen Umgang mit dem o. g. Fehler.

In meinem Fall gibt der Benutzer einen prozentualen Zu- oder Abschlag auf einen Rechnungsbetrag ein. Im Ereignis "AfterUpdate" wird der absolute Wert ermittelt.
Beispiel:
Rechnungsbetrag = € 100,00
Zuschlag 12,53 %
Absoluter Betrag = € 12,53
Code:

Klar.

Nun sage ich aber immer: "Wer ein Programm richtig testen will muss sich auch mal mit dem Hintern auf die Tastatur setzen" *upps . Denn der Entwickler kann sich nicht ausmalen, was der Benutzer (versehentlich) anstellen kann.

Hab ich gemacht und einfach mal eine ellenlange Ziffernfolge im Eingabefeld erfasst, die bei der folgenden Berechnung des absoluten Wertes natürlich einen Überlauf erzeugt hat.

Natürlich prüfe ich die Eingabe vor dem Speichern in einer Plausi-Prüfung ausführlich ab (Prozentsätze > 100 und < -100). Aber das Zwischenergebnis, den absoluten Betrag, möchte ich "on the fly" ermitteln, damit der Benutzer eine Kontrollfunktion hat. Was also tun, um den Überlauf abzufangen?

• Mit dem Eingabeformat arbeite ich ungern, da es die Erfassung für den Benutzer erschwert und zu ungewohnt kryptischen Fehlermeldungen führt.
• Fehlerbehandllungs-Routine (OnError) wäre eine weitere Möglichkeit.

Ich habe mir jetzt eine Prüfung im Ereignis "AfterUpdate" gebastelt, die den Überlauf umständlich abfängt. Die könnte ich natürlich noch durch eine MsgBox erweitern, damit die Eingabe des Benutzers nicht unkommentiert verschwindet.
Code:

Ich wüsste gern, wie ihr mit diesem Thema umgeht und welche Vorgehensweise ihr für die sinnvollste haltet. Vielleicht habe ich ja gar nicht alle Möglichkeiten bedacht?

Vielen Dank im Voraus für alle Anregungen.
Michael O.

:)

 

Hallo Michael,

warum prüfst du nicht einfach auf eine Zahl und wenn es eine Zahl ist, ob diese in dem von dir gewünschten Bereich liegt?
Was du da machst ist "Textverarbeitung" und noch etwas: anstatt immer wieder mit der Funktion NZ() zu arbeiten, kannst du das einmal prüfen und dann direkt als unerlaubte Eingabe zurückweisen. Da gibt es nichts mehr zu prüfen.

Ulrich

 

Hallo,
mir ist unklar, was Du da prüfen willst.
Wo kommt denn da der Überlauf her ?

Code:

Erzeugt Text, Dein Feld ist dann keine Währung mehr.

 

Rechnungsbeträge, Zuschläge, Abschläge usw. wären in meiner Vorstellung Werte, die in Tabellenfelder gehören - wenn man damit richtig arbeiten und nicht nur Finger- und Codeübungen in einem Formular anstellen will (Flipper?).

Damit würde man einzuhaltende Regeln (Datentypen, Gültigkeitsregeln) bereits auf Tabellenebene einstellen, weil das dort umfassend und sicherer funktioniert. Das Rechnen erfolgt einfach und direkt in einer Abfrage, die kann auch hervorragend mit NULL umgehen und braucht keine Ereignisse. Das Formular zeigt dann nur Abfrageinhalte an und kann sich auf letzte Kosmetik des Ganzen beschränken.

Die Codediskussion würde so gesehen in nichts zusammenfallen.

 

Hallo Klaus,

der Überlauf tritt in dieser Code-Zeile auf:
Code:

wobei gilt:
txt_korr_proz_wert ist der eingegebene Wert
txt_rech_netto_alt ist zu korrigierende Rechnungsbetrag (Datenbank-Deld)

Ich möchte direkt nach Eingabe den absoluten Korrekturbetrag ausweisen. Bei sinnvollen Eingaben ist das unproblematisch, aber wenn jemand mit dem Finger auf der Tastatur einschläft und "666666666666666666666666666666666666666666..." eingibt kommt es zum Überlauf. Und es gibt ja immer mal Felder auf einem Firmular, die ausschließlich zum Rechnen benötigt werden und nicht in der DB stehen. Wie also schließt man ungültige Werte zuverlässig aus?

VG
Michael

 

hat dir mein Lösungsvorschlag nicht gefallen, daß du deine Frage nochmal stellst?

Ulrich

 

Hallo Ulrich,
keine böse Absicht. Wollte nur erfragen, ob es ggf. noch einen ganz anderen Denkansatz gibt, der mir bisher verborgen geblieben ist.
VG
Michael