Noob-Unicode Frage
-
Hi,
ich muss eine VC6 Anwendung um einen Dialog erweitern, wo Unicode unterstützt werden muss. Die restliche Anwendung ist ANSI und lässt sich aus verschiedenen Gründen derzeit auch nicht komplett auf Unicode umstellen. Die Daten sollen per UTF-8 in die Datenbank persistiert werden.
Hat jemand Tipps, wie ich das am problemfreiesten bewerkstelligen kann? Das Problem werde ich ja schliesslich nicht als erster haben....
-
Afaik dürfte es kein Problem sein, UNICODE und ANSI nebeneinander zu verwenden - du mußt nur daran denken, im UC-Dialog die W-Versionen der WinAPI-Funktionen explizit aufzurufen (die "normalen" Versionen werden im ANSI-Build auf A gemappt) - und Strings bei der Übergabe zwischen beiden Teilen umzuwandeln (dazu gibt's Konvertierungsmakros CT2CW() und CW2CT()).
-
Auf Plain Win32 API ist es theoretisch möglich in einem MBCS Projket direkt die Unicode Funktionen (CreateWindowW, also W im Namen) zu nutzen.
In der MFC geht das nicht. In der MFC von VC6 wird es noch schlimmer.
Die MFC ab 200x kent nicht nur CString, sondern CStringA und CStringW hier man man immer den gewünscten Support...
BTW: Datenbank und UTF-8? Was ist das bitte für ein Interface was Du da verwendest? Selbstgestrickt?
-
Die MFC kannst Du nur "entweder/oder" verwenden. Mir wäre es zumindest ein Rätsel wie es anders gehen sollte...
Also ohne MFC: Kein Problem.
Mit MFC: Stelle lieber gleich alles auf TCHAR um...
-
Martin Richter schrieb:
BTW: Datenbank und UTF-8? Was ist das bitte für ein Interface was Du da verwendest? Selbstgestrickt?
Ja. Die Erweiterung soll ihre Daten in einer neuen Tabelle in einer Nicht-Unicode-Datenbank ablegen, deswegen diese Notlösung mit UTF-8.
-
Jochen Kalmbach schrieb:
Mit MFC: Stelle lieber gleich alles auf TCHAR um...
Das ist relativ illusorisch. Der Code hat einen Umfang von ca. 60 Mannjahren und da sind die ganzen MS-Hilfsmittel für i18n wie z.B. _T() oder TCHAR konsequent ignoriert worden.
-
Dann bist Du festgenagelt...
-
CStoll schrieb:
Afaik dürfte es kein Problem sein, UNICODE und ANSI nebeneinander zu verwenden - du mußt nur daran denken, im UC-Dialog die W-Versionen der WinAPI-Funktionen explizit aufzurufen (die "normalen" Versionen werden im ANSI-Build auf A gemappt) - und Strings bei der Übergabe zwischen beiden Teilen umzuwandeln (dazu gibt's Konvertierungsmakros CT2CW() und CW2CT()).
Ja, das war so meine vage Vorstellung von der Lösung des Problems: die Daten in CStringWs halten und mit ::GetWindowTextW() bzw. ::SetWindowTextW() in bzw. aus dem Dialog pumpen.
Nur das mit dem CreateWindowW() blick ich nicht so richtig, da ist Unicode doch höchstens für lpClassName und lpWindowName relevant, oder?
-
Martin Richter schrieb:
Dann bist Du festgenagelt...
Worauf? Auf WinAPI Aufrufe? Ich bin ja schon froh, dass die Anwendung parallel zu meinen Aktivitäten von VC6 auf VS2005 umgestellt wird.
-
jencas schrieb:
Ja, das war so meine vage Vorstellung von der Lösung des Problems: die Daten in CStringWs halten und mit ::GetWindowTextW() bzw. ::SetWindowTextW() in bzw. aus dem Dialog pumpen.
Nur das mit dem CreateWindowW() blick ich nicht so richtig, da ist Unicode doch höchstens für lpClassName und lpWindowName relevant, oder?
1. CStringW gibt es in VC6 nicht!
2. Wird ein Fenster mit CreateWindowA angelegt, dann kann es keine UNICODE Daten halten, oder man kann keine eingeben. Alle Kommunikation muss dann über WM_...W Nachrichten erfolgen!
Die Art und Weise wie man ein Fenster erzeugt bestimmt sein Verhalten.
CreateWindowW hat deswegen weitausmehr Einfluß als dass es nur die Klasse und den Titel als wchar_t haben möchte!
3. Das gleiche erfolgt implizit durch Funktionen wie CreateDialogA/W etc.HTH
-
jencas schrieb:
Martin Richter schrieb:
Dann bist Du festgenagelt...
Worauf? Auf WinAPI Aufrufe?
Ja. Also MFC kannst Du nicht verwenden!
Mach es mit der WinAPI... und übersetze das Source-File mit _UNICODE *und* UNICODE! (und mach es mit TCHAR).
