1.9 und Umlaute

[Rudolf]

Hallo Leute,
habe jetzt mein erstes grösseres Projekt umgestellt von 1.82 auf 1.9. Bis auf ein paar Probleme mit eXPress++ und mxPushbutton funktioniert alles soweit. Nur mit den Umlauten habe ich noch ein Problem. Ich verwende bei beiden die international version. Beim MultiEdit habe ich den ANSI Font eingestellt. Bei der 1.82er ist alles ok mit den Umlauten, bei der 1.9 stimmen sie nicht mehr. Obwohl die selben Compilerschalter verwendet werden ist das Ergebnis unterschiedlich. Hat jemand ein ähnliches Problem oder einen Tip ? Grüsse
Rudolf

[andreas]

Hallo Rudolf,

ich habe mein Programm auch auf 1.9 umgestellt. Ich benutze allerdings die deutsche XBase Version. Bis Jetzt habe ich keine Probleme mit den Umlauten. Ich arbeite ausschlisslich mit XBase (keine externe Tools) und MultiEdit im Ansi-Modus.

[Jan]

Moin Rudolf,

ich benutze wie Andreas keine 3rd-party-Programme. Xbase++ pur, als Editor nehme ich VX. Und ich hatte weder mit 1.8, 1.82, 1.9 RC-sonstwas und 1.9 Beta, sowie 1.9 Final keinerlei Probleme mit Umlauten auf Buttons. Auch nicht in der 1.9-Testphase, wo es das ja nur in der internationalen Version gab.

Ich muss allerdings hinzufügen, daß ich meine Editoren grundsätzlich auf ANSI umgestellt habe, ich mache das nicht mehr in ASCI.

Jan

[Rudolf]

Hallo,
ich habe eben auch auf ANSI umgestellt, das dürfte das Problem sein. Aber im 1.82 hat alles normal funktioniert mit den Umlauten. Keine Ahnung wo der Unterschied liegt.
Grüsse
Rudolf

[brandelh]

Hallo Rudolf,

nur so zur Sicherheit:

• 1. KEINE Kompilerschalter aktiv ! (weder /GA noch /O) gibt nur Ärger.
  2. Quelltexte unter ANSI gespeichert ? (Notepad zeigt richtig an ?)
  3. im Quellcode SET CHARSET TO ANSI ?
  4. convToAnsiCP() entfernt ? doppelt gemoppelt gibt auch Fehler.
  5. DBFNTX sind in Datei immer OEM, bei FOXCDX hängt das vom CHARSET während der Erstellung ab ...

mehr fällt mir jetzt nicht ein.

[Manfred]

Hi,

wie sieht das denn im Hybridmodus aus? Worauf sollte man denn da auf jeden Fall achten? Insbesondere wenn es um Datenbankinhalte geht?

[brandelh]

Hallo Manfred,

im Hybridmodus hast du ja meist alten Clippercode.
Ich habe bisher immer in OEM gespeichert und auch den CHARSET so eingestellt. Mit den eigenen bzw. Clipper DBF (egal wie) kommt Xbase++ dann selbst sehr gut zurecht.

Nur wenn du auf das Dateisystem (schon mit FILE() ?) oder die API zugreifst (Dateiauswahl etc), werden die Umlaute nicht mehr richtig dargestellt und du must ConvToAnsiCP nutzen.

Bevor ich die Compilerschalter nutzen würde, setze ich lieber den Quellcode um (MED kann das, aber auch Xbase selbst:

Code: Alles auswählen

memowrit(cFile,convToAnsiCP(memoread(cFile)))

Sonst sucht man sich dämlich !

Grundsätzlich macht Win32 ALLES in ANSI, OEM habe ich nur noch, weil ich früher Clipper und die OS/2 Version genutzt habe. Beides tue ich nicht mehr und nun stelle ich gemütlich um.

[andreas]

Ich hatte früher ein Problem beim Umstieg auf GUI, wo ich die Fenster mit dem Designer von Alaska erstellt hatte. Der Designer speichert den Class-Code hauptsächlich in OEM. Wenn du die Captions dann mit Umlauten hast und Programm auf ANSI steht, bekommst du falsche Darstellung von den Umlauten.
Du muss im Programm bei allen Objekten die Captions ändern, wo Umlaute vorkommen.

[Rudolf]

Hallo Leute,
vielen Dank für die Tips. SET CHARSET TO ANSI hat geholfen. Sieht aus als ob die 1.9er wirklich funktioniert. Habe nur noch ein Problem mit mxPushbutton, aber Joe arbeitet daran. Angeblich hat er am Montag eine neue Version.
Grüsse
Rudolf

[Rudolf]

Jetzt habe ich noch ein Problem. Wenn ich in ein Multiline einen Text mit Umlauten eingebe und Programm dann vergleiche, funktioniert das Ganze nicht mehr. z.B.
Text im Multiline : "ÄNDERN"
dann verleiche ich: if "ÄNDERN" $ cText
aber es funktioniert nicht.
Habe Multiedit auf ANSI Font und SET CHARSTE TO ANSI im Programm.
Grüsse
Rudolf

[andreas]

Hallo Rudolf,

versuchs mit SET LEXICAL.

[andreas]

Hallo Rudolf,

versuchs mit SET LEXICAL und SetLexRule.

[Rudolf]

Hallo Andreas,
danke für den Tip, aber das Problem hat sich von selbst gelöst. Ich habe nochmal compliliert, und plötzlich funktioniert es. Keine Ahnung wieso es vorher nicht ging.
Grüsse
Rudolf

[Manfred]

Moin,

da dieser Thread hier Umlaute mit 1.9 behandelt, mache ich hier auch weiter..

So wie ich das bisherige Problem verstanden habe, dann ging es in der Hauptsache um Texte, die die Masken, bzw. die Bildschirmschriften betreffen.

Ich verstehe jetzt nicht so ganz, wie die Sache innerhalb der DB ist, wenn Umlaute vorhanden sind.

Wenn von Clipper nach Xbase++ migriert wird, was muß denn jetzt wie mit den Datenbanken passieren, die Umlaute beinhalten?

Von CLipper nach Xbase++ Textmodus
von Clipper nach Xbase++ Hybridmodus
Von Clipper nach Xbase++ GUI

Irgendwie kann ich es drehen und wenden wie ich will, es bleiben immer irgendwelche abstrakten Zeichen übrig, die falsch dargestellt werden.

Was muß wirlich beachtet werden?

[brandelh]

Hallo Manfred,

die Daten aus den DBF müssten ohne Zutun automatisch richtig sein. Alle DBFNTX Dateien (Clipper und Xbase Standard) speichern immer in OEM ab. Alle DBFCDX Dateien (nur Xbase) merken sich beim Erstellen wie die set charset Einstellung war und nutzen diese intern.

Einzige Ausnahme stellen alte MEMO-Felder dar. Dies aber nicht wegen der Umlaute, sondern weil dort eventuell noch von älteren Clipperversionen Zeilenumbrüche vorhanden sind. Clipper 5.x hat diese eigentlich auch schon gestört. Ich meine es war chr(141), welcher als kleiner Balken oder einem i mit schrägem Punkt dargestellt werden.

Hier kann man diese Teile suchen und entweder per Hand löschen und speichern oder automatisch Ersetzen mit strtran(), dann aber die genaue chr nummer suchen.

[Manfred]

Hi Hubert,

hm, ich lese die Daten aus der CLipper Db in den Speicher und schreibe sie dann in die neue DB. So wie es aussieht, passiert dort der Fehler.

Wenn ich dann das Ergebnis über den DBeditor ansehe, dann habe ich das Problem mit Umlauten.

PS: Nach erneutem Prüfen, scheint es wohl nur mit kleingeschriebenen Umlauten ein Problem zu geben.

[Manfred]

Ich glaube ich bin dem Fehler auf der Spur.

Ich bekomme Daten aus einer Textdatei, die alle groß geschrieben sind. Diese teile ich dann auf und konvertiere sie in ein DBF Format. Dann werden die Texte mit Tokenupper(lower(text)) umgewandelt und bei dem Lower() aus den Tools, entsteht der Fehler. Im Moment sieht es so aus, als wenn ein "Ü" nicht zu einem "ü" umgewandelt wird. Ich werde einmal die anderen Zeichen Schritt für Schritt prüfen.

PS: der fehler ist wohl schon bekannt, aber irgendwie kann ich die Sache nicht nachvollziehen.

http://www.alaska-software.com/scripts/ ... PDRID=4134

Ich habe gar kein SET COLLATION TO ASCII und trotzdem habe ich das Problem.

[brandelh]

Hallo Manfred,

wenn die Texte mit dem NOTEPAD 'richtig' angezeigt werden, dann sind sie in ANSI eingegeben worden, sonst wohl in OEM (wenn es unter Clipper ging, wird es wohl OEM sein). Beim Einlesen dieser Textdaten wird NICHT automatisch konvertiert, du mußt also auf verschiedene Sachen Rücksicht nehmen:

1. TXT in ASCII/OEM, set Charset to OEM und set collation to german
Die Daten müssten sauber in der DBF ankommen.
2. TXT in ANSI, set Charset to OEM und set collation to german
Die Daten müssen von ANSI nach OEM gewandelt werden:
replace cFeld with ConvToOemCP(cTxt)
3. TXT in ANSI, set Charset to ANSI und set collation to german
Die Daten müssten sauber in der DBF ankommen.
4. TXT in ASCII/OEM, set Charset to ANSI und set collation to german
Die Daten müssen von OEM nach ANSI gewandelt werden:
replace cFeld with ConvToAnsiCP(cTxt)

PS: upper() und lower() sind nicht aus den Tools, aber vielleicht macht dein Token... etwas anderes als du erwartest (versucht er alle umzusetzen ?).

[Manfred]

Hi Hubert,

sorry, Du hast Recht. Upper()Und Lower() sind nicht aus den Tools. Aber lower() macht trotzdem Probleme, wie man in der Knowledgebase auch nachlesen kann. Ich habe es direkt im Debugger von VX getestet.

Die Textdatei wird aus einem Windowsprogramm heraus erzeugt. Dort ist auch alles noch in Ordnung. Es hängt mit den Umlauten zusammen, wenn sie bearbeitet werden. Ich habe mir jetzt zum Testen nochmal eine kleinere Datei erzeugt. Es scheint auch irgendwie mit Buchstabenkombinationen zusammenzuhängen. Es ist nicht immer der Fall, dass die großgeschriebenen Umlaute nicht umgewandelt werden in Kleinbuchstaben. Ich habe aber bisher noch kein System dahinter entdecken können, warum es mal klappt und mal nicht.

[brandelh]

Hallo Manfred,

also bei meiner 1.90.331, genauso wie bei der 1.82 OHNE eigene DBESYS.PRG (dort wird standardmäßig auf deutsch eingestellt)

wird ein OEM Quellcode ? lower("ÄÖÜ") bzw. ? upper("äöü") richtig umgesetzt und im dosmodus angezeigt. Prüfe erst ob dies bei dir auch so ist. Möglicherweise hat VX die set charset to ansi option eingeschaltet, dann mußt du mit msgbox() den Erfolg anzeigen lassen.

Ansonsten prüfe mit notepad ob die TXT Datei in ANSI oder OEM vorliegt und convertiere im RAM wenn nötig.

[Manfred]

Ich zeige die TExtdatei mit dem internen Editor vom Totalcommander an. Der sagt mir, die liegt im Ansi Mode vor. Schalte ich auch ASCII um, dann habe ich Grütze bei den Umlauten.

Ich habe mir gerade den Ursprung am Textbildschirm anzeigen lassen. Da steht der Umlaut verkehrt.

Jetzt gehe ich mit COnvToOEMCP() dran. Fürs 1. sah es vernünftig aus.

Merkwürdig, ich meine ich hätte es schon mal probiert. Aber so wie ich mich kenne, habe ich das andere benutzt. Das klappt natürlich nicht.