Inoffizielles deutsches Xbase-Forum

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

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:

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!

was täte ich blos ohne Euch Ihr lieben Forenmitglieder!

Ich glaube, diese Frage stellen sich hier viele (ich eingeschlossen).

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.

Ein weiteres Beispiel sind Dateinamen mit Umlauten

Ein weiteres Beispiel sind Dateinamen mit Umlauten

Jup. Wenn man mit OEM arbeitet, sind FileDialoge und alles, was damit zusammenhängt, ein Späßchen für sich.

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.

Tom hat geschrieben:Bei ActiveX-Controls übernimmt der Compiler (bzw. die Laufzeitumgebung) die Konvertierung.

weiss jemand ob man das in Xbase++ abstellen kann ?

Die EXE gleich auf ANSI laufen lassen

brandelh hat geschrieben:Die EXE gleich auf ANSI laufen lassen

das habe ich versucht aber es gibt keinen (Geschwindigkeits-) Unterschied bei Mappoint obwohl 2 x Konvertiert wird ( ANSI -> OEM -> ANSI )

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.

Die ANSI / OEM Konvertierung wird über die API mit schnellen Funktionen erledigt, warum sollte das messbare Unterschiede ergeben ?

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.

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.

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.

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.

brandelh hat geschrieben:ob diese aber innerhalb von ActiveX grundsätzlich oder nur innerhalb der Xbase++ Implementation stattfindet kann ich nicht sagen.

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:Alles andere muss man selbst konvertieren.

wenn man OEM Daten hat / benötigt und diese z.b. an LL übergeben will-