Office: Textbox - Eingabe auf Zahlen beschränkt, trotzdem ein Symbol

Hallo Forum,

ich bin heute über einen (meinen) Fehler gestolpert:

Auf einem Blatt liegen mehrere ActiveX-Steuerelemente.
Eins davon ist eine Textbox, über die ich Mengenangaben eingebe, und die via Macro später dann weiter verarbeitet werden.

Damit Eingabefehler möglichst vermindert werden, habe ich mit folgendem Code die Eingabe in diese Textbox auf Ziffern begrenzt:

Code:

Private Sub TextBox2_Menge_KeyPress(ByVal KeyAscii As MSForms.ReturnInteger)
    
    'Eingabe nur Zahlen und Minus möglich
    If KeyAscii <> 45 And KeyAscii < 48 Or KeyAscii > 57 Then KeyAscii = 0

End Sub

Die Wirksamkeit habe ich ausreichend getestet (so dachte ich), Buchstaben etc. werden nicht mehr genommen.
Aber heute muss ich irgend etwas gedrückt haben, was trotzdem noch genommen wird, und ein Symbol (Fragezeichen in Rechteck) in der Zielzelle erzeugt.
(siehe Bild unten).


1. Frage: welche Taste oder Tastenkombi erzeugt dieses Symbol?

2. Frage: wie kann ich das bei der Eingabe verhindern? Sprich wie kann ich die Eingabe komplett auf die Ziffern 0 - 9 und das Minuszeichen begrenzen?

 

Hallo Achim,

ich hätte Zahlen so geprüft

Code:

'   Eingaben nur Zahlen
    Select Case KeyAscii
        Case 48 To 57
        Case Else: KeyAscii = 0
    End Select

[/code]

 

Hallo Hajo,

danke für Deinen Tipp.
Magst Du mir auch verraten warum Du Deine Schreibweise genommen hättest?
Wo ist der praktische Unterschied ob ich select case oder if nehme?
(verstehe ich grad nicht)



Mir ist gerade aufgefallen das ich mich im Eröffnungspost etwas missverständlich ausgedrückt habe (habs bereits ergänzt):

Das Symbol habe ich in der Zielzelle gefunden, es ist mir nicht in der Textbox aufgefallen (keine Ahnung obs da auch angezeigt wurde, denke eher nicht).

Die Zielzelle ist so

Code:

#0 __;[Rot]-#0 __

formatiert, und die Werteübegabe erfolgt so:

Code:

.Cells(letzteZeile, 4) = Workbooks(wkb1).Worksheets(wks1).TextBox2_Menge

mich ahnt gerade das:

Code:

.Cells(letzteZeile, 4) = CDbl(Workbooks(wkb1).Worksheets(wks1).TextBox2_Menge)

besser wäre.
Möglicherweise kann dann ja so ein Symbol nicht mehr erscheinen?
Oder ist das nicht notwendig durch das Zellformat?

 

Hallo Achim,

Du hast wohl übersehen das ich nur einer Vergleiuch habe von 48 bis 57. In Deinen Vergleich könnte ich mir nur mit sehr hohen Aufwand einarbeiten. Was ich mir nicht antue.

Gruß Hajo

 

Hallo Hajo,

ich hätte nicht gedacht das mein Code kompliziert erscheint.
Vielleicht interessiert es Dich ja doch.
Für den Fall habe ich ihn weiter unten "auseinandergedröselt".

Ich dachte auch eher daran ob es einen generellen Unterschied zwischen den Mehtoden gibt (Geschwindigkeit, guter Stil, Zuverlässigkeit, ... was auch immer).

Aber bezüglich meinen beiden Eingangsfragen bin ich noch nicht weiter.

Code:

If KeyAscii <> 45

wenn Nicht das Minuszeichen

Code:

And KeyAscii < 48

und kleiner als 48

Code:

Or KeyAscii > 57

oder größer als 57

Bedeutet:
wenn die Taste nicht das Minuszeichen ist, und auch nicht im Bereich 48 bis 57 (Ziffern) liegt, dann:

Code:

Then KeyAscii = 0 

In Deiner Schreibweise wäre das wohl:

Code:

Select Case KeyAscii
Case 45
Case 48 To 57
Case Else: KeyAscii = 0
End Select 

 

Hallo Achim,

was für eine Schriftart hast Du in der Zelle?

Gruß

Edgar

 

Hallo Edgar,

das ist "Calibri".
Ich ändere nur selten die Schriftart, deshalb habe ich normalerweise den voreingestellten Standard.

 

Re: Textbox - Eingabe auf Zahlen beschränkt, trotzdem ein Sy

Hmmm... Schauen wir mal...

32 (" "): true and true or false = true
45 ("-"): false and true or false = false
50 ("2"): true and false or false = false
65 ("A"): true and false or true = true

Der Meinung ist auch das Direktfenster des VBA-Editors. Hmmm... Demnach sollten eigentlich wirklich alle anderen Zeichen abgefangen werden. Und ich hatte zuerst auf einen Klemmer-Fehler getippt. Ich würde die beiden OR-Bedingungen nämlich alleine schon wegen der Übersichtlichkeit in ( ) setzen:

Code:

If KeyAscii <> 45 And (KeyAscii < 48 Or KeyAscii > 57) Then KeyAscii = 0

Nichtsdestotrotz würde ich eine CASE-Struktur, wie HaJo auch schon schrieb, vorziehen. Sie ist bedeutend übersichtlicher um weitere erlaubte Zeichen zu ergänzen. Denn das "+" könnte genauso dazukommen, wie ein "," oder "." oder sogar ein "E", wenn jemand auf die glorreiche Idee kommt, die Zahl 123 in Exponential-Schreibweise 1,23E+02 einzugeben. ;-)

Außerdem kann im CASE auch mehr passieren, als nur true/false zu setzen. Z.B. könnte ein Warnton oder eine Messagebox kommen oder was auch immer...

Woher das ? im Kasten kommt? Das dürfte primär vom Zeichensatz abhängen. Bei den meisten Fonts wird aber ein "unbekanntes" Zeichen nur als simples Quadrat angezeigt.

Ah, wo ich jetzt "Calibri" sehe und den Font sogar selbst auch habe: Jop, die "nicht darstellbaren" Zeichen werden dort als ? im Kasten angezeigt. (Bei mir ist "Arial" Standard.)

Du könntest genauer herausfinden, welches Zeichen das ist, wenn Du mit

Code:

=code(links(a1))

den ASCII-Zeichencode ausgibst. Wobei diese Formel davon ausgeht, daß das merkwürdige Zeichen in Zelle A1 an erster Stelle der Zeichenkette steht...

So, wie ich das sehe, müßte es wahrscheinlich ein Zeichen zwischen 0 und 31 sein, sonst höchstens noch 127 oder 143. Die anderen Zeichen bis 255 scheinen alle "darstellbar" zu sein.

Gruß, Michael

 

Re: Textbox - Eingabe auf Zahlen beschränkt, trotzdem ein Sy

Und wieder was gelernt.
Wußte bisher nicht das man dort auch Klammern setzen kann.

Okay, die CASE-Struktur ist übersichtlicher, universeller, und einfacher anzupassen.
Das ist ne Begründung.
Auch wenn ich in diesem Fall gerade wirklich nichts anderes als Minus und Ziffern benötige, werd ichs trotzdem umschreiben. (zum angewöhnen)

Und noch was gelernt.
Diese Formel kannte ich auch noch nicht.

Als Ergebnis spuckt sie mir 9 aus, also den Tab-Key.
Hm.
Ich springe mit dem Tab-Key von Box zu Box...
Aber eigentlich sollte das dann ja nicht IN einer Box erscheinen.
Ist auch bisher nur einmal aufgetreten.

Irgend eine Idee wie man sowas verhindern kann?
Zum Beispiel im Enter-Ereignis, oder so?

 

Re: Textbox - Eingabe auf Zahlen beschränkt, trotzdem ein Sy

In einigen Programmiersprachen ist es sogar Pflicht, jede einzelne Aussage zu klammern, spätestens wenn 2 Bedingungen ins Spiel kommen.

Einer der Gründe ist, den Vergleich zwischen zwei Bedingungen klar von bitweisen Operationen zu trennen.

Code:

a = b and c = d

ist auf den ersten Blick klar. Die Gesamt-Aussage ist nur wahr, wenn a=b ist und außerdem c=d ist. Im "Kleinen" passiert hier:
a=b ergibt z.B. "wahr"
c=d ergibt z.B. "falsch"
Dann steht da:

Code:

wahr and falsch

Und da bei "and" beide Seiten "wahr" sein müssen, ergibt das Ding als Endergebnis "falsch".

Aber wie sieht's bei

Code:

a=b and c

aus?

Code:

a=3
b=4
? a=b
Falsch

Ok, das war offensichtlich, denn a ist ganz klar nicht gleich b.

Code:

c=5
? a=b and c
 0

Huch? Gegenprobe...

Code:

b=3
? a=b and c
 5

Jetzt schlägt's 13...

Mit diesem Beispiel haben wir das Feld der "überprüfe Aussage auf wahr/falsch" verlassen. Das "wahr" wird intern auch als "-1" gesetzt, was bedeutet, daß alle Bits (duales Zahlensystem) dieser Zahl, inklusive dem "Vorzeichen-Bit" ganz links auf "1" stehen. Der Zustand "falsch" wiederum wird intern durch "0" dargestellt.

Code:

? true*1
-1
? false*1
 0

Und was passiert jetzt bei "a=b and c"? Nun, zuerst wird "a=b" ausgewertet und entsprechend "true" oder "false" errechnet. Das wiederum wird mittels bitweisem "and" mit c verknüpft. Das bedeutet, jedes Bit, das in z.B. "wahr" gesetzt ist, mit jedem Bit von b, also z.B. "5", verglichen wird. Sind beide gesetzt, wird das entsprechende Bit im Ergebnis gesetzt. und "11111111 and 00000101" ergeben "00000101" und somit "5".

Und jetzt einer für Dich:

Code:

? a=(b and c)
Falsch

Jetzt kannst Du Dir sicher erklären, warum das Ergebnis so lautet. Und Du siehst, welchen Einfluß so eine blöde, kleine Klammerung haben kann..

Das "code()" entspricht dem "asc()" im VBA, das "links()" hat mit "left$()" sein Pendant.

Ach, TAB? Hmmm... Da war doch was...

OH zum Thema "KeyPress-Ereignis"...

Ah, genau, da stand's. Sind ein paar mehr Sätze, die relevant sind:

... und außerdem noch der Kram rund um "KeyDown", "KeyPress" und "KeyUp".

Damit wäre Deine KeyPress-Routine schon mal aus dem Spiel. Die wird gar nicht durchlaufen bei Drücken der TAB-Taste.

Jetzt schreibst Du aber:

Wenn das nicht wiederholbar immer wieder auftritt, wenn Du das Feld mit TAB betritts oder verläßt, dann wird's schwierig. Dann würde ich in letzter Konsequenz vielleicht sogar ein Fehlverhalten des Steuerelements selbst nicht ausschließen.

In dem Fall hättest Du gar keine Chance, wirklich effektiv dagegen vorzugehen. Da bliebe dann nur im "GotFocus" oder "LostFocus" den Text auf Steuerzeichen zu überprüfen und sie ggf. zu entfernen.

Gruß, Michael

 

Re: Textbox - Eingabe auf Zahlen beschränkt, trotzdem ein Sy

Hallo Michael,

Deine Erklärung ist ja mal wieder vom feinsten. ;O)

Kenn ich ja aus der Mathematik, ist mir auch alles logisch.
Da ich aber das Meiste meiner "Kenntnisse" aus Problemlösungen im Internet gezogen habe, und mir diese Klammern dort noch nirgendwo begegnet sind, bin ich garnicht auf die Idee gekommen das man dort welche setzen kann/sollte.
Und mit Erfahrungen aus anderen Programmiersprachen kann ich auch nicht Aufwarten.
Die einzige diesbezügliche "Erfahrung" ist gut 20 Jahre her und war Basic auf dem C64.
*lach*
Und auch dort nicht sehr tiefgehend.

Hm,
also im Normalfall ist die Textbox beim Betreten leer, die Boxen werden einmal der Reihe nach "abgelaufen".
Manchmal "springt" man aber (aus bestimmten Gründen) vom letzten Steuerlement zurück in eines aus der Reihe.
Wenn man dann wieder weiter geht, ist die Textbox natürlich schon befüllt.
Diesen Fall kann ich aber ausschliessen. Als das Symbol auftrat muss die Boxenreihe "normal" durchlaufen worden sein, die Textbox war beim Betreten also leer.
(nur zur Erklärung)


Der Sprung zur nächsten Box wird bei mir so ausgelöst:

Code:

Private Sub ComboBox1_Datum_KeyDown(ByVal KeyCode As MSForms.ReturnInteger, ByVal Shift As Integer)
    
    'mit TAB-Taste zur nächsten Box springen
    If KeyCode = 9 Then Me.ComboBox2_Vorgang.Activate

End Sub

Und dieses Ereigniss wird auch definitif abgearbeitet und ausgelöst.
Habe ich gerade noch getestet.


Wenn jetzt aber, aus irgendeinem Grund, ein Tastendruck sich durch die Reglementierungen schummelt (die ja scheinbar korekt und ausreichend begrenzt sind), dann könnte ich das natürlich verhindern, indem ich bei jedem Betreten der Textbox diese erstmal leere.

Code:

TextBox2_Menge = ""

Da sie normalerweise beim Betreten ja eh leer ist, und die genannte Ausnahme nur selten auftritt, könnte ich wohl damit leben, und hätte hoffentlich alle Fehlerquellen damit erschlagen.

Was anderes fällt mir gerade nicht wirklich ein.

Erstens wüßte ich nicht wie ich "den Text auf Steuerzeichen zu überprüfe", und zweitens ist das vermutlich wieder etwas aufwändiger, bzw. schwierig zu machen wenn es wirklich komplett sein soll.

Oder hat jemand einen anderen Tipp?

 

oder würde dies:

Code:

.Cells(letzteZeile, 4) = CDbl(Workbooks(wkb1).Worksheets(wks1).TextBox2_Menge)

die Problematik verhindern?

 

Re: Textbox - Eingabe auf Zahlen beschränkt, trotzdem ein Sy

Bei mir sind die Homecomputer eher 30 Jahre her, so ab 78 oder 79... Zu der Zeit habe ich primär Basic, Pascal und Assembler auf dem TI99/4A benutzt. Ein bißchen C auch noch, aber daran konnte ich mich nie so recht gewöhnen. Dummerweise komme ich an C-mäßiger Syntax durch PHP nicht mehr ganz vorbei, aber irgendwas ist ja immer... ;-) (Forth, Logo, Comal, Lisp, Cobol und einige andere sind mittlerweile Geschichte.) Letztlich bin ich privat bei Pascal / Delphi hängen geblieben und beruflich ist VBA das Werkzeug, auch wenn ich es privat ebenfalls häufiger nutze.

Ach, das hält sich eigentlich in Grenzen. Ich häng mal zwei Dateien mit an, die ich mir vor einiger Zeit gebastelt hatte:

Die eine ist eine Übersicht über die Zeichen eines Zeichensatzes. Du brauchst nur den Font in der Zelle ändern, wo der Fontname drin steht und die Zelle dann z.B. mit "Return" verlassen. Die darüber liegenden Zeichen werden dann im neu eingestellten Font dargestellt. Der Zellen-Kommentar nennt Dir dann auch den Zeichencode, zusätzlich zum Herx-Code, der sich aus Spalten- und Zeilen-Beschriftung zusammensetzt.

Die zweite stellt ein Tastatur-Layout dar, mit dem Du sehen kannst, auf welchen Tasten welche Zeichen in einem bestimmten Font liegen. Das ist primär vielleicht für diese Symbol-Fonts (Webdings, Wingdings oder wie sie noch alle heißen) interessant, hilft aber auch bei exotischeren Fonts zu überprüfen, ob benötigte Zeichen (Umlaute usw.) überhaupt verfügbar sind.

Wenn Du jetzt in der 1. mal "Calibri" einstellst, wirst Du sehen, daß die Zeichen 0 bis 31 sowie 127 und 143 als [ ] dargestellt werden, während alle anderen Zeichen normal darstellbar sind. Das ist soweit auch völlig ok, denn laut ANSI, ASCII und Konsorten befinden sich die Steuerzeichen immer im Bereich von 0 bis 31. die 127 ist so'n "halbes" Steuerzeichen, wird tlw. als "DEL" interpretiert, meistens aber als "Blank". Die 143 sagt mir jetzt so nichts, aber eigentlich ist alles ab 128 eh nicht mehr wirklich genormt. Der ASCII-Zeichensatz geht eigentlich sogar nur bis 95. Der Bereich ab 96 (u.a. die Kleinbuchstaben) gehören schon zum "erweiterten" ASCII-Satz.

Wäre blöd, wenn ich jetzt so viel getippselt hätte und dann jetzt "Nein" antworten würde, oder? ;-)

Wenn Du ungewünschte Steuerzeichen entfernen möchtest, wäre die einfachste Art, die replace() Funktion von VBA zu nutzen. In einer Schleife oder ggf. auch einzelnen Anweisungen könntest Du dann der Reihe nach alle unliebsamen Zeichen durch "" ersetzen.

Code:

s=replace(s,chr$(9),"")

würde z.B. das "TAB" Zeichen aus dem String enrtfernen.

Code:

for c=0 to 31
  s=replace(s,chr$(c),"")
next c

würde alle Zeichen von 0 bis 31 entfernen. Da VBA aber nicht gerade zu den Speed-Boliden gehört, erst recht nicht, wenn es um String-Behandlung geht, würde ich solche Operationen möglichst sparsam einsetzen.

Für den Anwender ist es sicher sehr störend, wenn er bei jedem Betreten oder Verlassen eines Eingabefelds immer so'n kurzes Stocken von 1, 2 Sekunden bekommt. Also sowas immer sehr kritisch ausprobieren...

Gruß, Michael

 

Hallo Michael,

sry das ich erst jetzt antworte.
Habe mir ganz kurzfristig eine kleine Auszeit gegönnt.

Deine beiden Dateien sind ja nette kleiner Helferlein. ;O)


Zum eigentlichen Problem:
Ich werde es im Auge behalten ob der Fehler irgendwann noch einmal auftritt.

Bis dahin habe ich die Werteübergabe in

Code:

.Cells(letzteZeile, 4) = CDbl(Workbooks(wkb1).Worksheets(wks1).TextBox2_Menge)

abgeändert, und hoffe das dadurch ja eigentlich nur Zahlen genommen werden können.

Desweiteren habe ich, wie schon durch Hajo empfohlen, die Prüfung auf

Code:

    'Eingabe nur Zahlen und Minus möglich
    Select Case KeyAscii
        Case 45             'Minuszeichen
        Case 48 To 57       'Zahlen
        Case Else: KeyAscii = 0
    End Select

geändert.


Auf die String-Prüfung verzichte ich lieber, denn in der Praxis wäre es gerade an dieser Stelle echt nervtötend, wenn jedesmal eine Verzögerung auftritt.

Im Endeffekt hoffe ich, das es ein "einmaliger" Fehler von Excel war, und das er nicht allzu oft auftritt.
Passiert ja schon ab und an mal das Excel den Code schneller durchläuft als er abgearbeitet wird, und dadurch dann eine Zeile "geschludert" wird.


Lieben Dank für Eure Zeit Hilfe.
Bis zur nächsten Frage.