"30.000000000000" in Int umwandeln?

[Stefan3110]

Hallo

Ich bekomme aus einer XML Datei einen String. Diesen String möchte ich jetzt in einen Integer umwandeln. Wie kann ich das am besten machen?

Wobei ich dazu sagen muss der String sieht zum Beispiel so aus: 30.000000000

Diesen möchte ich dann in den Integer 30 umwandeln. Dies bekomme ich aber nicht hin. In einen Double bekomme ich ihn. Aber der Double wert ist dann immer viel zu groß (30x10hoch16).

Danke und viele Grüße
Stefan

[Bernhard Geyer]

Wie ist auf dem PC der Dezimaltrenner und das Tausender-Trennzeichen definiert?

[Oliver Michalski]

Hallo Stefan,

mich würde interessieren, wie Du deinen String in Integer verwandeln wolltest. Bei System.Convert.ToInt32(30.00000000000) würde der Punkt in der Stringdarstellung auf jedenfall eine Formatexception auslösen. Erlaubt sind nur Ziffern und optional ein Vorzeichen.

Gruß Oliver

[Jürgen Thomas]

@Oliver
Ganz so stimmt es nicht. Es gibt nämlich auch eine Überladung, mit der man eine bestimmte Formatierung (z.B. Tausender-Trenner) angeben kann. Aber genau danach fragt doch Stefan.

Er hat zwei Probleme: Er weiß nicht, wie er aus einem double einen int machen kann. Und seine double-Zahl ist nach seinem Empfinden falsch. Deshalb hat ja Bernhard nach der double-Formatierung des PC gefragt.

Ich wollte eigentlich nicht antworten, sondern erst einmal auf Stefans Auskunft warten. Aber bevor die Diskussion jetzt in eine falsche Richtung läuft:

1. Die Methoden der Convert-Klasse sind möglichst zu vermeiden. Besser sind immer (soweit vorhanden) Parse, TryParse, ParseExact, TryParseExact - im konkreten Fall Double.TryParse().

2. Wenn Dezimal- und Tausendertrenner nicht "wie erwartet" interpretiert werden, ist eine Überladung mit einem geeigneten IFormatProvider zu wählen. Das ist einer der Gründe, warum ich immer den Blick in die SDK-Doku empfehle, in der diese Varianten vorgeschlagen werden.

3. Erst nachdem der String in eine Zahl verwandelt worden ist (also double), kann die Rundung als int folgen; denn eine Dezimaldarstellung passt (insofern hat Oliver natürlich recht) niemals zu einem int. Das geht ganz einfach mit (int) oder mit Math.Round().

Jürgen

[Stefan3110]

Hallo

Danke für Eure Antworten. Bei dem Problem geht es darum das ich eine SharePoint Liste habe in welcher die Zahl 30 in einer bestimmten Spalte steht. Ein InfoPaht Formular liest nun die 30 aus der Liste und fügt sie in ein Formularfeld ein. Wobei beides eigentlich XML Dateien sind. In XML gibt es eigentlich keine Dateitypen sondern es kann nur die Formatierung angepasst werden. Darum steht im Formular wieder die 30.0000Periode. Dieses Feld möchte ich jetzt nutzen um ein anderes Feld zu kontrollieren (< oder >). Darum frage ich per C# Code das Feld "Rest = Convert.Double(xml.SelectSingleNode("/my:Rest", NamespaceManager).Value);" ab. Da XML aber die amerikanische Notation verwendet erkennt das System dann nicht 30 sondern eine viel größere Zahle 300000000000000. Der Punkt wird nicht als Komma angsehen sondern als Tausender-Trenner und ignoriert. Natürlich haut somit auch meine Prüfung nicht hin. Darum meine Frage. Vielleicht kann ich jetzt zu etwas Klarheit beitragen.

Viele Grüße
Stefan

Testete gerade Parse. Selbes Ergebniss. Ich bekomme nicht die 30 sondern 3hoch10*14.

[Jürgen Thomas]

2. Wenn Dezimal- und Tausendertrenner nicht "wie erwartet" interpretiert werden, ist eine Überladung mit einem geeigneten IFormatProvider zu wählen. Das ist einer der Gründe, warum ich immer den Blick in die SDK-Doku empfehle, in der diese Varianten vorgeschlagen werden.

Also für Leute, die solche Tipps nicht verstehen und nicht selbst in der SDK-Doku nachlesen können: Benutze die Variante Double.TryParse-Methode (String, NumberStyles, IFormatProvider, Double) und orientiere Dich an dem Beispiel, das dort steht. Jürgen

[3Huete]

Testete gerade Parse. Selbes Ergebniss. Ich bekomme nicht die 30 sondern 3hoch10*14.

Hallo,
trenne doch einfach die 30 vor dem Punkt mittels Split ab.

string	strBeispielZahl	= "30.000000000000000";
int	intBeispielZahl	= 0;
char[]	Separator		= new char[] {'.'};
string[] strTeilStrings	= strBeispielZahl.Split(Separator);
intBeispielZahl		= Convert.ToInt32(strTeilStrings[0]);
MessageBox.Show("Beispielzahl = " + intBeispielZahl.ToString());

Gruß

[Jürgen Thomas]

@3Huete
Also wenn Du schon "Methode Holzhammer" verwenden willst, nämlich die Formatierung nicht typensicher untersuchen, sondern einfach an eine bestimmte Situation anpassen willst, dann mache es doch konsequent und benutze IndexOf und Substring, das geht schneller. Außerdem gilt weiterhin mein Hinweis auf TryParse.

Jürgen

[3Huete]

@3Huete
Also wenn Du schon "Methode Holzhammer" verwenden willst, nämlich die Formatierung nicht typensicher untersuchen, sondern einfach an eine bestimmte Situation anpassen willst, dann mache es doch konsequent und benutze IndexOf und Substring, das geht schneller. Außerdem gilt weiterhin mein Hinweis auf TryParse.

Jürgen

Stimmt, Substring hatte ich auch in Erwägung gezogen. Split hatte ich aber grad anderweitig verwendet.
Und bevor man es gar nicht hinbekommt, nutzt mal halt, bis einem was Besseres einfällt, auch mal 'nen Holzhammer.
Deinen Hinweis auf TryParse schaue ich mir heute Abend an. Jetzt gehe ich erst mal Boot fahren.
Gruß und sonniges WE

[3Huete]

Testete gerade Parse. Selbes Ergebniss. Ich bekomme nicht die 30 sondern 3hoch10*14.

Hallo,
dem Hinweis von Thomas folgend hab ich grad dieses hier ausprobiert:

double		dbZahl		= 0;
int		intZahl		= 0;
string		strZahl		= "30.00000000000000";
CultureInfo	ci		= new CultureInfo("en-US");
NumberFormatInfo	nfi		= ci.NumberFormat;
nfi.NumberDecimalSeparator		= ".";
if(Double.TryParse(strZahl, NumberStyles.Number, ci, out dbZahl)) {
        intZahl = (int)dbZahl;
}

Liefert 30.


Gruß

[Stefan3110]

Danke für Eure Hilfe. Es hat geklappt.

CultureInfo ci = new CultureInfo("en-US");
Int16.TryParse((xml.SelectSingleNode("/my:Rest", NamespaceManager).Value), NumberStyles.Number, ci, out Rest);

Ich kann die Zahl sogar als Int16 lassen, da sie nie größer wird als eine 16Bit Integer Zahl.

Ich musste auch noch

using System.Globalization;

ergänzen damit es ohne Fehler läuft

@Jürgen Deine Hilfe ist sehr gut. Nur manchmal solltest Du bedenken das auch Anfänger hier im Forum sind. So wie ich.

Viele Grüße
Stefan

[Jürgen Thomas]

Hallo Stefan,

Ich kann die Zahl sogar als Int16 lassen, da sie nie größer wird als eine 16Bit Integer Zahl.

Das ist kein Grund: Auf einem 32-Bit-Rechner benutzt auch ein Int16 volle 32 Bits. Im Gegenteil: Der Verwaltungsaufwand für den PC wird größer. Man kann also grundsätzlich einen "normalen" int benutzen - egal ob der Speicherbereich ausgenutzt wird oder nicht. (Das gilt z.B. auch für Enumerationen, die ja meistens nur eine geringe Anzahl von Elementen enthalten.)

Ich musste auch noch "using System.Globalization;" ergänzen damit es ohne Fehler läuft

Die using-Direktiven müssen nicht unbedingt sein. Man kann ja auch überall schreiben:

System.Globalization.CultureInfo ci 
    = new System.Globalization.CultureInfo("en-US");

Aber wir sind ja alle schreibfaul.

@Jürgen Deine Hilfe ist sehr gut. Nur manchmal solltest Du bedenken das auch Anfänger hier im Forum sind. So wie ich.

Danke; ich werde mich weiterhin bemühen und hoffentlich bessern. Jürgen

[csharper1984]

Wenn ich die CulturInfo auf en-US gesetz habe, dann sind diese beiden Befehle überflüssig, da nun der Punkt als Trennzeichen und nicht als Tausendertrenner angesehen wird.
Somit kommt doch schon durch einfache umstellung der CulturInfo die 30 raus.

NumberFormatInfo	nfi		= ci.NumberFormat;
nfi.NumberDecimalSeparator		= ".";

}

mfg
csharper1984

[3Huete]

Wenn ich die CulturInfo auf en-US gesetz habe, dann sind diese beiden Befehle überflüssig, da nun der Punkt als Trennzeichen und nicht als Tausendertrenner angesehen wird.
Somit kommt doch schon durch einfache umstellung der CulturInfo die 30 raus.
mfg
csharper1984

Hallo,
Du hast recht. Und Stefan3110 hat es auch schon so verkürzt umgesetzt. Ich hatte ursprünglich aber "de-DE" drinstehen
und habe nach Änderung die beiden anderen Zeilen stehenlassen um zu demonstrieren, was man da alles einstellen kann.
Die Anpassungsmöglichkeiten sind ja in der Tat nicht ganz unbeträchtlich.
Gruß