LL druckt Sonderzeichen falsch
Moderator: Moderatoren
- satmax
- 1000 working lines a day
- Beiträge: 831
- Registriert: Do, 02. Dez 2010 19:34
- Wohnort: Biberbach in Österreich
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 1 Mal
- Kontaktdaten:
LL druckt Sonderzeichen falsch
Hallo,
mein Projekt schreitet voran und der erste Ausdruck wird implementiert.
LL druckt alle Sonderzeichen aus der DB falsch. Gibt es da eine globale Einstellung oder muss ich jedes Datenbankfeld konverieren?
Gruß
Markus
mein Projekt schreitet voran und der erste Ausdruck wird implementiert.
LL druckt alle Sonderzeichen aus der DB falsch. Gibt es da eine globale Einstellung oder muss ich jedes Datenbankfeld konverieren?
Gruß
Markus
Gruß
Markus
Markus
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9357
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: LL druckt Sonderzeichen falsch
Wenn Deine Anwendung mit dem CHARSET OEM arbeitet, musst Du alle Zeichenfelder, die Du mit LLDefineField/Variable an L&L übergibst, mit ConvToAnsiCP(c) konvertieren:
Code: Alles auswählen
LlDefineFieldExt(nJob,<cFieldName>,ConvToAnsiCp(c),LL_TEXT,0)
Herzlich,
Tom
Tom
- satmax
- 1000 working lines a day
- Beiträge: 831
- Registriert: Do, 02. Dez 2010 19:34
- Wohnort: Biberbach in Österreich
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 1 Mal
- Kontaktdaten:
Re: LL druckt Sonderzeichen falsch
Danke, funktioniert super. Ich hab's gleich in die Function DefineData() eingebaut.
Gruß
Markus
PS: was täte ich blos ohne Euch Ihr lieben Forenmitglieder!
Gruß
Markus
PS: was täte ich blos ohne Euch Ihr lieben Forenmitglieder!
Gruß
Markus
Markus
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9357
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: LL druckt Sonderzeichen falsch
Ich glaube, diese Frage stellen sich hier viele (ich eingeschlossen).was täte ich blos ohne Euch Ihr lieben Forenmitglieder!
Grundsätzlich: Wenn Apps mit dem OEM-Zeichensatz arbeiten, muss bei allen DLL-Funktionen und - leider - hin und wieder auch bei der Verwendung von API-Funktionen konvertiert werden. Das ist nur dann unerheblich, wenn man bei entsprechenden Funktionen mit 7-Bit-ASCII arbeitet, also dem Zeichenbereich, der für ANSI und OEM gleich ist.
Bei ActiveX-Controls übernimmt der Compiler (bzw. die Laufzeitumgebung) die Konvertierung.
Herzlich,
Tom
Tom
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9357
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: LL druckt Sonderzeichen falsch
Jup. Wenn man mit OEM arbeitet, sind FileDialoge und alles, was damit zusammenhängt, ein Späßchen für sich.Ein weiteres Beispiel sind Dateinamen mit Umlauten
Es ist ja unproblematisch, eine App umzustellen, und dann kann man sich den ganzen Krempel sparen. Als Benefit wird auch die GUI etwas schneller, weil dort die interne Konvertierung wegfällt. Allerdings gibt es einen Haken, wenn nämlich die Tabellen alle in OEM sind, was bei DBFNTX Standard ist. Dann verlangsamt sich die App nach der Umstellung.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: LL druckt Sonderzeichen falsch
weiss jemand ob man das in Xbase++ abstellen kann ?Tom hat geschrieben:Bei ActiveX-Controls übernimmt der Compiler (bzw. die Laufzeitumgebung) die Konvertierung.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: LL druckt Sonderzeichen falsch
das habe ich versucht aber es gibt keinen (Geschwindigkeits-) Unterschied bei Mappoint obwohl 2 x Konvertiert wird ( ANSI -> OEM -> ANSI )brandelh hat geschrieben:Die EXE gleich auf ANSI laufen lassen
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: LL druckt Sonderzeichen falsch
Die ANSI / OEM Konvertierung wird über die API mit schnellen Funktionen erledigt, warum sollte das messbare Unterschiede ergeben ?
Der Vorteil einer EXE in ANSI liegt darin, dass es Zeichen gibt, die nach der OEM ANSI Konvertierung nicht mehr die Gleichen sind.
Wenn ich im Quellcode z.B. (r) ® in OEM Quellcode erfasse in Ansi anzeigen lasse, sehe ich kein ® im Programm.
Der Vorteil einer EXE in ANSI liegt darin, dass es Zeichen gibt, die nach der OEM ANSI Konvertierung nicht mehr die Gleichen sind.
Wenn ich im Quellcode z.B. (r) ® in OEM Quellcode erfasse in Ansi anzeigen lasse, sehe ich kein ® im Programm.
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9357
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: LL druckt Sonderzeichen falsch
Wenn ich mich recht erinnere, sprach S. P. auf irgendeiner DevCon davon, dass die Geschwindigkeit der GUI um bis zu 15% zunimmt, wenn man mit ANSI arbeitet, also die GUI nicht mehr konvertieren muss. Das ist sicher schwer messbar, da die GUI ja nur die Oberfläche ausmacht, während im Hintergrund jede Menge Geschäftslogik und Datenbankzugriffe ablaufen. Aber nachvollziehbar ist das schon, denn immerhin muss ja jeder String zeichenweise geprüft und konvertiert werden.Die ANSI / OEM Konvertierung wird über die API mit schnellen Funktionen erledigt, warum sollte das messbare Unterschiede ergeben ?
Allerdings würde ich beispielsweise bei der MapPoint-Schnittstelle keinen Zugewinn erwarten. Da betrifft es ja sowieso nur die Parameterübergabe; der Prozess an und für sich ist aber so intensiv, dass es darauf kaum ankommen dürfte.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: LL druckt Sonderzeichen falsch
hi,
auf die Umlaute bei Mappoint und die "automatisch" Konvertierung der activeX Schnittstelle bin ich jetzt erst durch meine Navi Auswertung gekommen.
Ich hatte eine Logbuch mitlaufen und da ist mir das mit ANSI / OEM aufgefallen wo ich fragte "warum" ?
"echte" Windows Controls arbeiten alle mit ANSI ( bzw. UniCode ) wie auch ein (unfertiges) XbpFileDialog() zeigt.
auch wenn ich DllCall Aufrufe machte benötige ich ANSI und kein OEM.
IMHO benötigt man automatische OEM<->ANSI Konvertierung nur für die DBE aber nicht wenn ich innerhalb ActiveX "lese" und dann den Inhalt wieder "schreibe".
wie ich schon sagte viel mir das im Logbuch auf das der "dual-fähige Code mit harbour anderes aussah als mit Xbase++
wobei beide die "richtige" Beschriftung der Mappoint Karte machten.
um die Geschwindigkeit geht es mir hier weniger ( 15% vs. 3000-4000% ) sondern das ich der automatischen Konvertierung nicht traue
wenn es sich nicht um Lateinische sondern Asiatische Zeichen (DBCS) handelt.
auf die Umlaute bei Mappoint und die "automatisch" Konvertierung der activeX Schnittstelle bin ich jetzt erst durch meine Navi Auswertung gekommen.
Ich hatte eine Logbuch mitlaufen und da ist mir das mit ANSI / OEM aufgefallen wo ich fragte "warum" ?
"echte" Windows Controls arbeiten alle mit ANSI ( bzw. UniCode ) wie auch ein (unfertiges) XbpFileDialog() zeigt.
auch wenn ich DllCall Aufrufe machte benötige ich ANSI und kein OEM.
IMHO benötigt man automatische OEM<->ANSI Konvertierung nur für die DBE aber nicht wenn ich innerhalb ActiveX "lese" und dann den Inhalt wieder "schreibe".
wie ich schon sagte viel mir das im Logbuch auf das der "dual-fähige Code mit harbour anderes aussah als mit Xbase++
wobei beide die "richtige" Beschriftung der Mappoint Karte machten.
um die Geschwindigkeit geht es mir hier weniger ( 15% vs. 3000-4000% ) sondern das ich der automatischen Konvertierung nicht traue
wenn es sich nicht um Lateinische sondern Asiatische Zeichen (DBCS) handelt.
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: LL druckt Sonderzeichen falsch
Soweit ich das beurteilen kann, nutzt Windows ab XP (?) intern immer UNICODE Controls.
Ansi / Unicode könnte beim Zugriff auf Controls intern automatisch konvertiert werden, wenn man die A Funktionen der API nutzt, ob das so ist weiß ich aber nicht wirklich.
OEM Konvertierung kann man aber bei vielen Controls als Feature einschalten (bei einem SLE %ES_OEMCONVERT - PowerBasic Formdesigner).
Was Xbase++ betrifft, gibt es eine automatische Konvertierung zwischen dem RAM Zeichensatz und den DBE und wohl auch zu ActiveX,
ob diese aber innerhalb von ActiveX grundsätzlich oder nur innerhalb der Xbase++ Implementation stattfindet kann ich nicht sagen.
Alles andere muss man selbst konvertieren.
Ansi / Unicode könnte beim Zugriff auf Controls intern automatisch konvertiert werden, wenn man die A Funktionen der API nutzt, ob das so ist weiß ich aber nicht wirklich.
OEM Konvertierung kann man aber bei vielen Controls als Feature einschalten (bei einem SLE %ES_OEMCONVERT - PowerBasic Formdesigner).
Was Xbase++ betrifft, gibt es eine automatische Konvertierung zwischen dem RAM Zeichensatz und den DBE und wohl auch zu ActiveX,
ob diese aber innerhalb von ActiveX grundsätzlich oder nur innerhalb der Xbase++ Implementation stattfindet kann ich nicht sagen.
Alles andere muss man selbst konvertieren.
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: LL druckt Sonderzeichen falsch
da ich ja den "dual" fähigen Code auch mit harbour compiliert habe und sich die Unterschiede im Logbuch ergaben ist der Beweis für mich erbracht "das" Xbase++ ein (unnötige) Konvertierung vornimmt.brandelh hat geschrieben:ob diese aber innerhalb von ActiveX grundsätzlich oder nur innerhalb der Xbase++ Implementation stattfindet kann ich nicht sagen.
wenn man OEM Daten hat / benötigt und diese z.b. an LL übergeben will-brandelh hat geschrieben:Alles andere muss man selbst konvertieren.
gruss by OHR
Jimmy
Jimmy