Probleme mit CDbl

14/10/2008 - 14:23 von Susann Markward | Report spam
Hallo,

wie castet man eigentlich unter VB.Classic richtig?

Normalerweise dachte ich bisher, dass die Cxxx-Funktionen hierfür das
geeignete Mittel der Wahl sind. Aber bspw. bei "CDbl" gibt es Probleme.
Wenn ich auf einem deutschen Windows einen String wie "123,45" mit CDbl
caste, geht alles glatt. Auf einem amerikanischen Windows nicht.

Mit Val("x.x") scheint es jedoch auf keinem OS Probleme zu geben.

Gibt es für die Casting-Funktionen CBool, CStr, CInt und CLng auch
unerwünschte Effekte bei einem Wechsel des OS?

Auf das Problem aufmerksam geworden bin ich durch Folgendes:
Ich nutze für die Initialisierung meines Programms eine MS Access
Datenbank. Dort gibt es eine Tabelle mit zwei Spalten. Beide Spalten
haben als Felddatentyp den Typ "Text". In der ersten Spalte steht ein
Variablen-Name und in der zweiten Spalte steht der Variablen-Wert.
Dieser Variablen-Wert kann indirekt alle unterschiedlichen Typen beinhalten.
Nach dem Start meines Programms greife ich auf Spalte 1 zu und lese den
dazugehörigen Wert. Wenn dort bspw. "123.45" steht, liefert CDbl auf
einem deutschen OS jedoch nur 123. Auf einem amerik. OS liefert CDbl
jedoch den korrekten Wert, nàmlich 123.45. Val hingegen liefert mir auf
einem deutschen OS 123,45 und auf einem amerikanischen OS 123.45. Sollte
man dann vielleicht immer Val und als Trennzeichen den Punkt nehmen?

Gibt es für CDate, CSng, CVar und CCur auch solche Nebeneffekte?

Wie macht ihr das bei Eurer Software?

MfG
Susann
 

Lesen sie die antworten

#1 Christian Zimmermann
14/10/2008 - 15:24 | Warnen spam
Hallo Susann,

Susann Markward schrieb:


wie castet man eigentlich unter VB.Classic richtig?

Normalerweise dachte ich bisher, dass die Cxxx-Funktionen hierfür das
geeignete Mittel der Wahl sind.



Korrekt. Gebietsschemaabhàngig formatierte Zeichenfolgen werden mit den
Cxxx() Funktionen konvertiert.

Aber bspw. bei "CDbl" gibt es Probleme.
Wenn ich auf einem deutschen Windows einen String wie "123,45" mit CDbl
caste, geht alles glatt. Auf einem amerikanischen Windows nicht.



Ja, weil das Deutsche Gebietsschema eben den Punkt als
Tausendertrennzeichen und das Komma als Dezimaltrennzeichen eingestellt
hat. Das amerikanische Format ist umgekehrt, somit müßte auch die
Ausgangszeichenfolge anders aussehen.


Mit Val("x.x") scheint es jedoch auf keinem OS Probleme zu geben.



Doch. Val() will immer "123.45" als Format und nichts anderes. Und das
ist gut so ;-)


Gibt es für die Casting-Funktionen CBool, CStr, CInt und CLng auch
unerwünschte Effekte bei einem Wechsel des OS?

Auf das Problem aufmerksam geworden bin ich durch Folgendes:
Ich nutze für die Initialisierung meines Programms eine MS Access
Datenbank. Dort gibt es eine Tabelle mit zwei Spalten. Beide Spalten
haben als Felddatentyp den Typ "Text". In der ersten Spalte steht ein
Variablen-Name und in der zweiten Spalte steht der Variablen-Wert.
Dieser Variablen-Wert kann indirekt alle unterschiedlichen Typen
beinhalten.
Nach dem Start meines Programms greife ich auf Spalte 1 zu und lese den
dazugehörigen Wert. Wenn dort bspw. "123.45" steht, liefert CDbl auf
einem deutschen OS jedoch nur 123. Auf einem amerik. OS liefert CDbl
jedoch den korrekten Wert, nàmlich 123.45. Val hingegen liefert mir auf
einem deutschen OS 123,45 und auf einem amerikanischen OS 123.45. Sollte
man dann vielleicht immer Val und als Trennzeichen den Punkt nehmen?

Gibt es für CDate, CSng, CVar und CCur auch solche Nebeneffekte?



Die Probleme entstehen nur dann, wenn aus einem String ein numerischer
Typ oder ein Datumstyp abgeleitet, "gecastet", werden soll. Zwischen den
numerischen Typen und auch dem Datumstyp kann ohne Probleme gecastet
werden, da die VB-intern immer gleich aufgebaut sind. Wie die OH ja auch
sagt, muss der zu konvertierende String abhàngig von dem Gebietsschema
des OS formatiert sein, damit daraus in jedem Falle korrekt das
numerische Pendant abgeleitet werden kann.

Wie macht ihr das bei Eurer Software?



Darstellung und Eingabe immer gebietsschemaabhàngig, da dies der
Anwender entsprechend seinen Einstellunegn gewohnt ist und auch so
nutzt. Die Speicherung der Werte in Stringform formatiere ich
gebietsschemaunabhàngig, und somit immer im gleichen Format, z. B. per
Str() Funktion oder "zu Fuß", d. h. keine Tausendertrennzeichen und der
Punkt als Dezimaltrenner. Beim Einlesen würde der String dann mit der
Val()-Funktion in ein numerisches Format gewandelt. Das funktioniert
dann unter jedem Gebietsschema. Datumsformate als Zeichenfolge speichere
ich in der Regel immer so: YYYYMMDDHHNNSS und interpretiere sie
entsprechend. Mit DateSerial() und TimeSerial() làßt sich daraus auch
leicht wieder ein Typ Date konstruieren.

Gruß

Christian

Ähnliche fragen