CAMSEdit: Invalid character value for cast specification

estartu

---------------------------
Audiodatic_III
---------------------------
Invalid character value for cast specification

---------------------------
OK
---------------------------

Diese Meldung bekomme ich, wenn ich ein CAMSCurrencyEdit verwende und dort einen Betrag mit Komma eingebe.
Ich finde die Stelle nicht, wo ich eingreifen müßte, ich finde nichtmal, woher die Meldung kommt.

Weiß jemand Rat?

Edit:
Ich vermute, das da hat was damit zu tun:

// Returns the current text as a double value.
double CAMSEdit::NumericBehavior::GetDouble() const
{
	return _tcstod(GetNumericText(m_pEdit->GetText()), NULL);
}

Was macht die Funktion, wenn man sie mit 32,80 füttert?

isabeau

Ins Blaue hinein:
hast du schon mal einen Punkt statt Komma versucht ?

estartu

Ja, ich kann keinen Punkt eingeben, der wird nicht angenommen.

Wenn ich 80.65 tippe steht 8065 im Edit. Das Komma nimmt er immerhin an.

Manfred Schmidtke

Liegt wohl an _tcstod, welches die lokalen Einstellungen benutzt. Hier ist halt das Komma üblich. Nach MSDN kann dies über setlocale geändert werden.

estartu

Mit setlocale hab ich es versucht.

Da ich aber nicht so ganz begriffen habe, was ich da tue, hat es wohl nicht funktioniert.

Ich habe das in InitInstance stehen:

// Das Hauptfenster ist initialisiert und kann jetzt angezeigt und aktualisiert werden.
	m_pMainWnd->UpdateWindow();

	_tsetlocale(LC_ALL, _T("German"));

Ist das richtig so? Oder die falsche Stelle?
Es hat jedenfalls keinen Effekt.

Manfred Schmidtke

Jetzt bin ich erstmal richtig verwirrt. Verstehe ich das richtig, das Du unbedingt den Punkt als Komma haben willst?

Das setlocale (LC_ALL, "german") hier keinen Effekt hat, sehe ich eigentlich als völlig korrekt an, da Dein System wahrscheinlich ohnehin auf Deutsch eingestellt sein dürfte.

Wenn das Komma durch den Punkt ersetzt werden soll, müsste hier eigentlich setlocale (LC_MONETARY, "english") greifen.

estartu

Nein, ich möchte nicht den Punkt als Komma haben.

Ich möchte, dass der Benutzer (DAU) einen Geldbetrag per Nummernblock eingeben kann. Da ist das Komma, was die ganzen Euros, von den Cents trennt.
Wenn ich nun 98,53 eingebe und versuche, zu speichern (also Wert auslesen und in Datenbank packen) dann bekomme ich die Meldung, die ich oben geschrieben habe.

Ich habe keine Ahnung, wo die herkommt. Auch ein Unterbrechen des Debug, was bei Messageboxen hilft, hatte keinen Erfolg. Es war kein bekannter Quellcode im Callstack.

Also stochere ich im Morast, was da wohl nicht stimmt...

Manfred Schmidtke schrieb:

Das setlocale (LC_ALL, "german") hier keinen Effekt hat, sehe ich eigentlich als völlig korrekt an, da Dein System wahrscheinlich ohnehin auf Deutsch eingestellt sein dürfte.

Okay, dann nehme ich es wieder raus.

Manfred Schmidtke

Da liegt das Problem m. E. wohl eher in den Datenbank-Einstellungen. Wenn die bei numerischen Werten unbedingt den Punkt braucht, muss man ihr den wohl auch liefern. Ich sehe daher nur die Möglichkeit, die Strings beim Einlesen und Schreiben entsprechend zu konvertieren, also das Komma in einen Punkt wandeln und umgekehrt.

estartu

Irgendwie habe ich langsam was anderes im Verdacht, aber immernoch keine Ahnung.

Wenn ich ändere (statt Neueingabe), dann bekomme ich diese Meldung:

---------------------------
Audiodatic_III
---------------------------
Invalid character value for cast specification
Invalid character value for cast specification

---------------------------
OK
---------------------------

EGAL, was ich eingebe - also ob mit Komma oder ohne.

Kann das der ODBC-Treiber sein? Ich arbeite mit MSDE2000 und die Felder sind vom Typ "money".
In der Datenbank steht auch nur 80 und nicht 80,00 oder 80.00

Was nun?

Manfred Schmidtke

Ich habe mal in der "Bibliothek" gestochert und ein Buch von 1995 zu ODBC gefunden. Der Typ Money ist ein reiner ODBC-Typ und erwartet scheinbar eine etwas andere Syntax:

INSERT INTO T1 (name, betrag) VALUES ('Joe', $123.45)

Dieseer Ausdruck ist korrekt. Das Dollarzeichen wird benötigt, um den maximalen Wert auszudrücken, den MONEY-Spalten aufnehmen können, denn ohne das Dollarzeichen wird der Wert als eine Umwandlung von einem Gleitkomma- oder Integertyp betrachtet, die beide nicht die Genauigkeit von MONEY bieten.

(aus INSIDE ODBC von Kyle Geiger).

In dem Schinken habe ich jedoch nichts zum Thema Lokalisierung gefunden.

Es bleibt wohl nichts weiter übrig, als hier über eine Konvertierungsfunktion zu gehen oder von vornherein nur mit Stringfeldern zu arbeiten. Das hat eine Menge Vorteile in Bezug auf Kompatibilität (kenn schließlich alle DBMSe) und man kann sich die Konvertierung sparen (sofern man mit dem Programm in Deutschland bleibt!).

estartu

Dann wird es wohl ein varchar werden.
Das mit dem $ hatte ich auch in meinem Buch gelesen, aber ich habe keinen Schimmer, wie ich das in meine CRecordset-Klasse einbauen soll.

Danke für deine Meinung.

Das Programm soll in Deutschland bleiben - sonst habe ich sowieso ein Problem...