Datentypen String auf JTextField wird zu Char-Array und anschließend zu int

PanCave

Mitglied
Hallo Leute,

ich stehe vor einem Rätsel:

Ich habe ein JTextField, dessen Inhalt ich mit
Java:
MeinJTextField.getText().toCharArray
in einen (logischen) Char-Array verwandele.
So weit, so gut. Wenn ich "5" (ohne ") eingebe und den Wert aus dem Char-Array auslese, gibt mir die Konsole auch tatsächlich wieder "5" (ohne ") heraus.
Auch gut, ABER: Wenn ich nun sage
Java:
int i = MeinCharArray[0];
Dann bekomme ich als reinen Zahlenwert IMMER die eingegebene Zahl + 48 (warum zur Hölle 48??) heraus, also in diesem Beispiel wäre i dann 53.

Ich habe durch spezielle Abfragen alles andere ausgeschlossen, es muss so sein, dass er
Java:
int i = MeinCharArray[0];
die Eingabe + 48 zuweist.

Wiesoooooo? 😀
Und: Wie kann ich das ändern, also dass er die richtige Zahl speichert (und bitte sagt mir nicht ich solle
Java:
int i = MeinCharArray[0]-48;
schreiben 😀)

LG PanCave
 
Auch gut, ABER: Wenn ich nun sage
Java:
int i = MeinCharArray[0];
Dann bekomme ich als reinen Zahlenwert IMMER die eingegebene Zahl + 48 (warum zur Hölle 48??) heraus, also in diesem Beispiel wäre i dann 53.
Wei die Zahlen, die wir sehen nicht die Zahlen sind, mit denen der Computer rechnet:
American Standard Code for Information Interchange ? Wikipedia

48 (oder genauer 30h) ist der ASCII-Code für die Ziffer "0"

bye
TT
 
Stichwort: ASCII.

53 ist der ASCII Wert des Buchstaben 5.
dementsprechend 54 von Buchstabe 6 etc.

Was du machen möchstest ist einen String zu einem int machen. So wie du es programmiert hast wird halt der int Wert des Buchstabens in deine Variable geschrieben. Was du brauchst ist die Funktion parseInt der WrapperKlasse Integer.

Guck dir die einfach mal an.

Doch Vorsicht, du mußt dann natürlich sicherstellen, das auch nur Zahlen eingegeben werden können, oder halt immer prüfen, ob es sich um eine Zahl handelt...
 
Und: Wie kann ich das ändern, also dass er die richtige Zahl speichert (und bitte sagt mir nicht ich solle
Java:
int i = MeinCharArray[0]-48;
schreiben 😀)
Java:
int i =Integer.parseInt(String.valueOf(MeinCharArray[0]))
Habe ich aber nicht getestet, kann also sein dass da auch wieder 5+48 raus kommt, denn eigentlich soll man das so machen:
Java:
int i =Integer.parseInt(MeinJTextField.getText())

bye
TT
 
Ah das ist doof, weil ich nämlich genau weiß, dass NICHT NUR Zahlen kommen werden...
Dann müsste ich den String zum CharArray machen, alle nicht Zahlen rauswerfen, daraus einen String machen und das dann als int speichern?
 
Ah das ist doof, weil ich nämlich genau weiß, dass NICHT NUR Zahlen kommen werden...
Dann müsste ich den String zum CharArray machen, alle nicht Zahlen rauswerfen, daraus einen String machen und das dann als int speichern?
Nein,
Man kann den String mittels regulärer Ausdrücke parsen (siehe Pattern) und dann die Zahlen entsprechend bearbeiten.

Oder besser eben kein universelles Eingabefeld bereit stellen, sondern jede Info gesondert abfragen und mittels [JAPI]JFormattedTextfield[/JAPI] und/oder [JAPI]InputVerifier[/JAPI] nur gültige Eingaben zulassen.

bye
TT
 
Das geht nicht, weil ich wie gesagt auch nicht-zahlen drin haben werde (immer).

Und jede Information einzeln abfragen, das würde die Optik zerstören.

Edit: Mir fällt eben auf, dass ich ja einfach split benutzen könnte 😀
 
Normalerweise ja, aber ich brauche kein Date, sondern ich brauche daraus lediglich die Sekunden.
Deshalb lohnt es sich nicht das umzuformen 🙂

Ich will nur ausrechnen lassen können wie viele Sekunden 02:54:36 sind 😉
Und das habe ich jetzt mit diesen zwei Zeilen geschafft:

Java:
String [] zeit = tex_zeit.getText().split(":");
		verbleibende_zeit = Integer.parseInt(zeit[2])+Integer.parseInt(zeit[1])*60+Integer.parseInt(zeit[0])*3600;
 
Vorsicht vor
Code:
split
mit nur einem Parameter. Das macht oft nicht das, was man möchte.

Teste mal, was bei anderen Eingaben der Art 10:15, 0:10:15:07, 10::04 oder 10::05:07 etc. herauskommt / passiert.
 
Ich habe in früheren Projekten split bereits getestet und kenne die Schwächen.
Allerdings sind hier die Umstände zufällig so, dass eine falsche Eingabe zu 97% unwahrscheinlich ist und sollte dennoch eine erfolgen wird ein Fehler ausgegeben.
 

Neue Themen


Zurück
Oben