Domino 9 und frühere Versionen > ND8: Entwicklung

CDbl will Komma statt Punkt zur Dezimalentrennung???

<< < (3/5) > >>

flaite:
Mein Vorgesetzter hatte genau damit große Probleme in einer Webanwendung mit dojo.
Es hing von sehr vielen Faktoren ab wie Domino Strings internationalisierte. Ich bekomme es nicht mehr hin. Vermutlich sollte er darüber bloggen. Es war nämlich echt  kompliziert, was er da herausgefunden hat.
a h
Es stimmt natürlich, dass die meisten Programmiersprachen intern die englischen Regeln verwenden. Nur ist das hier irrelevant. Sobald du die Zahl über http schickst mußt du sie erst in einem String umwandeln, um sie dann im empfangenen wieder in einen Double umzuwandeln. Das hat nicht einmal etwas mit http zu tun, sondern mit verteilten Systemen. Zahlen werden auf diesem Planeten jede Zehntelsekunde tausendfach als Strings an andere Systeme verschickt, die sie dann als Zahlen weiterverarbeiten. Hier halte ich Bernhards Aussage für einfach nicht realistisch.

Du wirst es ja an nicht so wahnsinnig viel Stellen benötigen, Marco. Du kannst vorher eine Funktion aufrufen, die dir ermittelt mit welchem Trennzeichen CDouble auf dem System heute funktioniert:
zu Not halt auch so:

--- Code: ---function getTrenner() As String
String nmbr = "4,2"
double res = CDouble(nmbr)
if (res = 4.2) then
return ","
else  
nmbr = "4.2"
res = CDouble (nmbr)
if (res = 4.2) then
return "."
else
return "?"
end if
end if
end if
end function

--- Ende Code ---
So ungefähr, nur ohne Syntaxfehler und eleganter  ;D

Oder vielleicht bekommst du das einfacher aus dem von Martin erwähnten international.DecimalSep.
Nun musst du im zu CDoublenden String nur das Trennzeichen in das richtige replacen.

heini_schwammerl:

--- Zitat von: Gandhi am 26.09.10 - 01:09:04 --- Dann überweise ich mal schnell hundert mal so viel Geld wie vorher....

--- Ende Zitat ---
Wird schon einen Grund haben das z.B. beim Online Banking immer 2 Felder (Euro- und Centbetrag) definiert sind. ;)
Bei kleinen Projekten im deutschsprachigen Raum filtere ich in der einfachen Lösung den Punkt in der Regel vorher einfach raus. Da ich das schon ein paar Jahre mache kann die Problematik nicht neu sein. Allerdings haben sich Windows Server hier bei mir deutlich angenehmer verhalten während z.B. Linux Server früher immer rumgezickt haben und ich tw. Definitionen über die notes.ini mitgeben musste.

Gandhi:
Ich habe das mit NotesInternational.DecimalSeparator gelöst, insofern ist das akute Problem damit für mich gelöst.
Dennoch halte ich das ganze für höchstproblematisch.
Wenn CDbl abhängig von den lokalen Einstellungen unterschiedliche Ergebnisse liefert, bedeutet das, dass jeder HTTP Transfer, also z.B. auch jeder Webservice, der mit  Zahlen arbeitet das handhaben muss - vor allem muss man erst mal wissen, dass man das handhaben muss (wenn man nur auf englischen System arbeitet wird einem das vermutlich nie ins Bewusstsein kommen - bis das System dann auf einem nicht englischen System ausgerollt wird).
Der Nutzen des Ganzen erschließt sich mir nach wie vor nicht.
Der Aufwand das zu lösen ist nicht groß und ich brauche es tatsächlich nur an 2 Stellen - aber dass das Problem existiert muss man erst mal wissen.
Ich werde mir das am Montag auf jeden Fall noch mal auf alten Versionen anschauen - mir ist das noch nie aufgefallen - und ich arbeite ja auch schon ein paar Jahre mit dem Produkt.  Ggf. ist das ein echter Fallstrick für das Upgrade auf höhere Serverversionen (wie gesagt, im Moment nur eine Vermutung).



Und nur mal so das Zitat aus der Designer Hilfe:
Datatype Doule - LotusScript:

--- Zitat ---The range of Double values is -1.7976931348623158E+308 to 1.7976931348623158E+308, inclusive.
On UNIX platforms, the range is -1.7976931348623156E+308 to 1.797693134862315E+308, inclusive.
--- Ende Zitat ---
Da steht mal gerade gar nichts darüber, dass hier unterschiedliche Dezimaltrennzeichen Anwendung finden können.
Zu cdbl steht auch nichts von Dezimaltrennzeichen.
Ich glaube also nicht, dass sich z.B. ein amerikanischer Entwickler, der ja durchaus auch für den Weltmarkt Anwendungen entwickeln kann darüber bewusst ist.

Und noch eine eindringliche Warnung:
   CStr(CDbl(CStr(PI)))
   "" & CDbl("" & PI)
kommt nicht zum gleichen Ergebnis!

Ich bin mir vollkommen bewusst, dass "" & NUMBER nicht abgesichert ist - benutzte das aber selbst häufiger im guten Glauben, dass das funktioniert (was es auch abgesehen von den Länderdezimalen bislang tat) und habe das auch schon sehr oft in fremden Code gesehen.
Mit dem nun gefundenen "Verhalten" ist das eine Bombe.

Glombi:
Es sind schon Raumsonden ungebremst in den Marsboden geknallt, weil die Programmierer ft und m verwechselt haben.

Soweit zum Thema

--- Zitat ---Ich glaube also nicht, dass sich z.B. ein amerikanischer Entwickler, der ja durchaus auch für den Weltmarkt Anwendungen entwickeln kann darüber bewusst ist.

--- Ende Zitat ---
Bei der KW-Formatformel gibts ja auch nur die amerikanische Sichtweise. Zum Glück fahren die rechts...


Den Vorschlag, zwei getrennte Felder für EUR und Cent zu nehmen, halte ich für sehr sinnvoll. Da gibt es dann keine Missverständnisse.

Andreas

Pyewacket:
Das böse Spiel geht noch weiter, auch bei Ucase/Lcase kann es Unterschiede geben,
je nachdem wie die aktuelle Plattform eingestellt ist.

Mit der Einstellung Deutsch oder Englisch gilt:

Ucase("i") = "I"

Ist die Ländereinstellung auf Türkisch eingestellt stimmt das nicht mehr, im
türkischen gibt es zusätzlich zu unserem grossen I noch ein grosses I mit Punkt drauf (İ).


Peter

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete