welche Codepage? [ERLEDIGT]

[Manfred]

Hi,

ich erkläre mal kurz den Ablauf:

1) Es wird aus einem Fremdprogramm eine Tabelle exportiert als Textdatei
2) Diese Textdatei wird danach in eine DBF konvertiert (nicht fragen, ist so und bleibt so)
3) Dann wird die DBF in ein Programm übernommen.

Im Moment ist es so, dass Fremd --> Text ein Windowsprogramm ist
Text --> DBF ein PHP Script im Konsolenmodus
DBF konvertieren in ein Xbase++ GUI Programm


Meine 1.Frage lautet nun, wie soll das Fremdprogramm exportieren damit obiger Weg möglichst reibungslos klappt in Sachen Umlaute. Codepage 437 oder Codepage 1252?

Wenn alles fertig ist, dann wird es so aussehen:

1) Fremdprogramm erzeugt Textdatei
2) Xbase++ GUI konvertiert nach DBF (auch nicht diskutieren, muß auch so bleiben)
3) Xbase++ GUI übernimmt DBF in bestehende Daten.

Was müßte dann gewählt werden als Export Codepage 437 oder 1252.

Das alles sollte möglichst ohne ConvTo... geschehen. Ist das möglich?

Im Moment ist alles Kraut und Rüben in Sachen Umlaute.

PS: Und vor allen Dingen, wie sieht es mit Set Charset aus? Wie muß dass denn dann wann und wodrauf stehen? Bzw. wie müssen die Compilerschalter /ga /go bei welchem Betriebsmode stehen?

[AUGE_OHR]

hi,

Codepage "wirkt" IMHO nur wenn man einen Font hat. Beim Export / Import ist aber kein Font im Spiel.
Wenn das "Fremdprogramm" auf einem "deutschen" Windows OS() eine "Text" (CVS, SDF) erzeugt ist die üblicherweise ANSI.

a.) DBFNTX ist immer OEM, also musst du FOXCDX verwenden.

b.) SET CHARSET OEM ist default, also sollte du es auf ANSI umstellen.

Damit müsste die DBF dann, ohne ConvToOEMCP(), den Import durchführen.




nun kommen wir zur "Ausgabe" der DBF am Bildschirm oder Drucker wofür wir einen Font brauchen.

a.) Wenn du einen OEM Editor benutzt wird durch /ga /go dein Source nach ANSI konvertiert.

b.) als FONT würde ich die "plattformunabhängige Schriftarten-Namen" aus FONT.CH nehmen.
Damit "sollte" NationMsg() die richtige Codepage ausgewählt werden.

[Manfred]

Puh,

Das das alles so kompliziert ist.

ich nutze die VX im "Standardmodus" und DBFCDX. Ich habe es mit Set Charset Ansi mal kurz probiert und schon ist der Rest wild durcheinander. Für mich ist es immer noch wichtig genau zu wissen ob und wenn ja wann, beim Schreiben in eine DBF Ansi<->OEM irgendeine Konvertierung stattfindet. Wenn ich die Daten in der DBF erstmal richtig stehen habe, dann wäre mir schon geholfen. Ich habe mal zu Probe mit verschiedenen Editoren eine DBF angesehen. Wenn die Ansicht ANSI ist und die Umlaute zu lesen sind, dann ist alles richtig vom Grunde her, oder wie darf ich das verstehen?

[brandelh]

Hallo Manfred,

eigentlich ist es am Besten wenn so wenig wie möglich umgesetzt wird.
Aber das wird sich nicht ganz vermeiden lassen, wobei die "normalen" Umlaute kein Problem darstellen.
Wenn du aber auch französische Umlaute, € (Euro) oder © etc. im Datenmaterial hast, könnte das Problematisch werden.
Übel wirds wenn dein Kunde französische Zählzeichen haben will "1er" müsste nämlich eigentlich ein hochgestelltes "er" erhalten.

Die 437 ist daher eine schlechte Wahl, da diese einige europäische Sonderzeichen nicht abbilden kann, daher wurde ja auch die 850 eingeführt.
Am sichersten bist du mit der Methode:

1. Datendatei in ANSI (1252)
2. Quellcode in ANSI
3. SET CHARSET TO ANSI
4. FOXCDX Treiber und Datei neu mit Xbase++ erstellen lassen also auch in ANSI

Wenn das mit der FOXCDX DBF nicht geht, und nicht nur einfache deutsche Umlaute kommen, ist es im Prinzip egal ob du die EXE in ANSI oder OEM erstellst,
aber wenn die EXE in OEM ist und der Quelltext mit z.B. memoedit() eingelesen wird, dann wird wahrscheinlich eine ConvToOemCP() nötig werden.

Ich habe SEHR GUTE Erfahrungen mit ANSI EXE und DBFNTX (automatische Umsetzung), aber ich habe in meinen Texten normalerweise keine ungewöhnlichen Sonderzeichen.

PS: das €-Zeichen muss man erst freischalten in Xbase++

PPS: wenn DBU die Datei öffnen kann und die Umlaute sauber anzeigt, ist es eine OEM Datei (DBFNTX).
wenn Xbase++ eine FOXCDX neu anlegt, dann wird es eine ANSI Datei.
Ob sich dein PHP Script an diese Regeln hält weiß ich nicht
(AmiPro hat sich damals darüber weggesetzt und einfach immer ANSI geschrieben )

[brandelh]

Hi,

also das mit dem © und dem ® Problem, das ich im Kopf hatte, muss ich zurücknehmen.
In meinem "Umlaut-Testprogramm" von gestern, habe ich das eben probiert.
Auch mit OEM Quellcode und OEM DBF wird das ordentlich umgesetzt, allerdings kann man mit DBU keine © Zeichen eingeben,
da ...

ANSI © == ALT+0169
OEM/ANSI ® == ALT+169

Mit einem Windowsprogramm das in die OEM DBF schreibt, kann man beide Zeichen erzeugen,
ein DOS Programm ignoriert die 0 vor der 169 ...
Bei einem Zeichensatz von 437 fehlen halt einige Sachen, aber wahrscheinlich meinen die eh 850.

Es ist KEIN Hexenwerk, einfach nachdenken, das Schaubild in der Hilfe nochmals ansehen und eine Linie halten.

[Manfred]

Hi Hubert,

ich habe gestern einmal das Experiment gemacht.

1) Datei als Windows 1252 exportieren lassen.
2) PHP Script laufen lassen
3) DBF die daraus entstanden ist mit dem DBF-Zusatz für den Total Commander geöffnet (ANSI) Umlaute waren zu sehen

Womit ich aber generell Probleme habe, ist es das Euro Zeichen in meiner GUI darzustellen.

[brandelh]

Womit ich aber generell Probleme habe, ist es das Euro Zeichen in meiner GUI darzustellen.

DAS IST KOMPLIZIERT !!!!

Code: Alles auswählen

SetLocale( NLS_ICURRENCYEURO, "1" )  // Eurozeichen
:setCaption := "EUR = €"

Nicht alle Zeichensätze und Betriebssystem enthalten es, aber eigentlich sollten alle Rechner und XP sowieso heute damit zurecht kommen

[brandelh]

Hi Hubert,
ich habe gestern einmal das Experiment gemacht.
1) Datei als Windows 1252 exportieren lassen.
2) PHP Script laufen lassen
3) DBF die daraus entstanden ist mit dem DBF-Zusatz für den Total Commander geöffnet (ANSI) Umlaute waren zu sehen

Kann DBU die Datei öffnen und die Umlaute stimmen nicht ?

Wenn JA, dann ist die DBF nicht "Normgerecht", aber dafür gibt es dennoch einen Schalter:

DBFDBE_ANSI a .F. L Ist die Einstellung .T., wird für DBF/DBT-Dateien das ANSI-Format verwendet
(in diesem Falle würde ich die Datei einfach umsetzen)

Wenn NEIN, dann ist es vermutlich eine FOXCDX DBF und somit völlig OK !

[Manfred]

Hubert, Du Schelm....

Womit ich aber generell Probleme habe, ist es das Euro Zeichen in meiner GUI darzustellen.

DAS IST KOMPLIZIERT !!!!

Code: Alles auswählen

SetLocale( NLS_ICURRENCYEURO, "1" )  // Eurozeichen
:setCaption := "EUR = €"

Nicht alle Zeichensätze und Betriebssystem enthalten es, aber eigentlich sollten alle Rechner und XP sowieso heute damit zurecht kommen

Genau das habe ich so, aber es bringt nur Murks zur Anzeige. Entweder einen Unterstrich, oder ein anderes komisches Zeichen. Und egal, wie ich die VX einstelle (no Conversion, Ansi<->OEM, oder umgekehrt), es erscheint kein "€" Zeichen.

Der DBU ist noch unter Clipper kompiliert und zeigt die Umlaute dann falsch

[brandelh]

Hi Manfred,

OK, wenn du das so hast, muss ich mich für die Frechheit entschuldigen.

Wenn du das € Zeichen im Programm in SLE oder MLE mit ALT+E eingeben kannst, dann ist dein Rechner und dein Programm richtig eingestellt.
Wenn nicht, fehlt entweder diese Zeile ... oder die Eurounterstützung. Einfacher Test, Notepad ... ALTGR+E

Ich kann das € Zeichen in meinem MED nicht im Quellcode eingeben, da erscheint auch im ANSI Modus immer ein '_' (unbekanntes Zeichen).
Ich verweise nochmals auf mein Testprogramm von gestern:

Code: Alles auswählen

GraStringAt( oPS, { nLR,nPosY  }, "Eurozeichen (kann ich im OEM Editor nicht eingeben): Chr(213)='"+Chr(213)+"'" )

also wie bei anderen "seltsamen" Zeichen hilft chr(), hier chr(213) - nicht zu verwechseln mit der Eingabe des Codes (ALT+213 bringt 'ı' )

[Manfred]

Nee Hubert, als Frechheit hatte ich das nicht interpretiert. Das würde ich Dir nie und nimmer zutrauen. Den Humor hatte ich schon herausgelesen..

Das mit dem Eurozeichen war auch nur ein Hinweis, das Symbol habe ich bisher immer elegant umschifft. Kommt aber sicherlich nochmal später, dass ich das genauer testen werde.

Für mich wäre für den Anfang nur nochmal eines wichtig. Für die reinen Daten in einer DBF: Ansi? Komme ich damit relativ sorgenfrei überall hin? Oder ist das jetzt doch alles von Fall zu Fall verschieden?

Wenn ich nämlich wenigstens die DBF schonmal richtig bestückt habe, dann kann ich den Rest danach aufbauen und anpassen. Im Moment weiß ich wirklich nicht, wo ich den Anfang machen soll.

[brandelh]

Der DBU ist noch unter Clipper kompiliert und zeigt die Umlaute dann falsch

Somit hast du "nicht normgerechte" DBFNTX Dateien !

sprich, das PHP script hält sich zwar an den logischen Aufbau, aber nicht an den vorgeschriebenen Zeichensatz.

Hierbei hast du das Problem besser die Herausforderung , dass Xbase++ davon nichts wissen kann !

Es gibt hier zwei Möglichkeiten:

1. EXE in OEM

jetzt "denkt" Xbase++ alles OK und konvertiert nichts intern, nur beim Schreiben in die SLE und beim Lesen von den SLE ... ANSI nach ANSI => Schrott
Lösung: DBFDBE (DATA-Komponente) => DBFDBE_ANSI a .F. L Ist die Einstellung .T., wird für DBF/DBT-Dateien das ANSI-Format verwendet
Ich habe das aber nie gemacht, also prüfen ob es funktioniert. Notfalls selbst die ANSI DBF Daten mit ConvToOemCP(field->AnsiInhalt) -> umwandeln.

2. EXE in ANSI

jetzt "denkt" Xbase++ es muss immer beim DBF lesen/schreiben umsetzen, gleiches Ergebnis, nur schon früher ... ANSI nach ANSI => Schrott
Lösung: DBFDBE (DATA-Komponente) => DBFDBE_ANSI a .F. L Ist die Einstellung .T., wird für DBF/DBT-Dateien das ANSI-Format verwendet
Ich habe das aber nie gemacht, also prüfen ob es funktioniert. Eine ConvToOemCP(field->AnsiInhalt) Notlösung geht hier nicht !!!

Eventuell kannst du dem Script beibringen, dass es FOXPRO (also FOXDBE) Dateien erzeugen soll, dann würde alles stimmen.
Wenn nicht, würde ich die Daten per Programm selbst umsetzen

Code: Alles auswählen

USE AnsiDBF via DBFNTX
DbeInfo( DBFDBE_ANSI, .t. )   // nun sollte Xbase++ wissen was in der DBF steht.
copy to AnsiFox via FOXCDX 

*** Quellcode ungetestet nur zur Anregung ***

[Manfred]

OK,

das Problem ist jetzt, dass immer wieder FoxCDX genannt wird. Ich habe aber CDXDBE im Einsatz.

Und alles andere hört sich im Moment recht umfangreich an. Ich werde mir zunächst einmal die Anleitung über die Treiber genau durchlesen, vielleicht klärt sich ja dann der Nebel schon ein wenig mehr.

[brandelh]

Hallo Manfred,

ich bin mir nicht sicher, ob man diesen ANSI-Schalter "pro Datei" setzen kann.
Wenn du eine GUI im OEM Modus hast, kannst du die "falsche" DBF aber in eine "richtige" umkopieren, da Xbase++ dann nichts daran ändert.

Code: Alles auswählen

SET CHARSET TO OEM  // SONST KANN DIES NICHT FUNKTIONIEREN, da die automatische Korrektur einsetzt.
// standard DBF Format ist DBFDBE => der Index spielt hier noch keine Rolle, WÄRE SPÄTER aber problematisch (ANSI-Umlaut # OEM-Umlaut !)
use AnsiDbf alias DBA
copy to OemDbf RECORD 1 // so erzeugen wir einfach eine strukturgleiche DBF 
use OemDbf alias DBO  NEW exclusive // gleicher Feldaufbau !
ZAP
nAnz := DBA->fcount()
do while ! DBA->(eof())
    for x := 1 to nAnz
       DBO->(FieldPut( x, convToOemCP(DBA->(fieldget(x))) )) // replace
    next
    DBA->dbskip()
enddo

das Problem ist jetzt, dass immer wieder FoxCDX genannt wird. Ich habe aber CDXDBE im Einsatz.

PS: Die FOXDBE ist die einzige DBE, deren DBF standardmäßig ANSI enthalten dürfen - es hält sich aber nicht jeder daran
Welche Index-DBE dann benutzt wird ist erstmal zweitrangig, aber natürlich ist es FATAL, wenn Xbase++ einen falschen Zeichensatz annimmt.
UPPER() etc. muss schon genau wissen, bei welchem chr() Ä, Ö Ü liegt und dass ä, ö, ü dazu gehören.

ANSI und OEM sind hier aber nicht identisch !
Somit kann ein upper("ä") nur dann ein "Ä" ergeben, wenn Xbase++ vom richtigen Zeichensatz ausgeht.

[Manfred]

Hi Hubert,

ich will ja gar nicht umkopieren. Ich suche nur nach dem besten Weg direkt von Anfang den richtigen Zeichensatz zu haben. Es muß jetzt einmal richtig sein und darauf baue ich dann auf. Aber wenn ich mir die Anleitung durchlese, entferne ich mich immer weiter vom Verstehen der Sache.

das ist z.B. meine DbeSys

Code: Alles auswählen

PROCEDURE dbeSys()
          /*
           *   Der Parameter lHidden wird fr alle Database-Engines, die zu
           *   einer abstrakten Database-Engine kombiniert werden, auf .T. gesetzt.
          */
          LOCAL aDbes := {;
                          { "DBFDBE", .T.},;
                          { "CDXDBE", .T.},;
                          { "DELDBE", .F.},;
                          { "SDFDBE", .F.};
                         }
          LOCAL aBuild :={ { "DBFCDX", 1, 2 } }
          LOCAL nI

          /*
           *   Setzen der Sortierfolge und des Datumformates
          */
          SET COLLATION TO GERMAN
          /*
           *   Laden aller Database-Engines
          */
          FOR nI := 1 TO LEN(aDbes)
              IF ! DBELOAD( aDbes[nI][1], aDbes[nI][2])
                 Alert( aDbes[nI][1] + MSG_DBE_NOT_LOADED , {"OK"} )
              ENDIF
          NEXT nI

          /*
           *   Erzeugen von Database-Engines
          */
          FOR nI := 1 TO LEN(aBuild)
              IF ! DBEBUILD( aBuild[nI][1], aDbes[aBuild[nI][2]][1], aDbes[aBuild[nI][3]][1])
                 Alert( aBuild[nI][1] + MSG_DBE_NOT_CREATED , {"OK"} )
              ENDIF
          NEXT nI

          IF ! DbeLoad( "NTXDBE",.T. )
             Alert( "Database-Engine NTXDBE konnte nicht geladen werden!", {"OK"})
          ENDIF
          IF ! DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )
             Alert( "DBFNTX Database-Engine konnte nicht erzeugt werden!", {"OK"})
          ENDIF
          DbeInfo(COMPONENT_DATA,DBFDBE_LIFETIME,0)
          DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED) // macht das die Massenabfertigung schneller? (29.10.2008)
          RETURN

wenn ich stattdessen DbeLoad("cdxdbe") mache, dann erscheint eine Fehlermeldung das die ungültig ist. Aber in den Beispielen im Handbuch steht es so, das man es so machen kann.

Code: Alles auswählen

PROCEDURE dbeSys()
          /*
           *   Der Parameter lHidden wird fr alle Database-Engines, die zu
           *   einer abstrakten Database-Engine kombiniert werden, auf .T. gesetzt.
          */
          LOCAL aDbes := {;
                          { "DBFDBE", .T.},;
                          { "CDXDBE", .T.},;
                          { "DELDBE", .F.},;
                          { "SDFDBE", .F.};
                         }
          LOCAL aBuild :={ { "DBFCDX", 1, 2 } }
          LOCAL nI

          /*
           *   Setzen der Sortierfolge und des Datumformates
          */
          SET COLLATION TO GERMAN
          /*
           *   Laden aller Database-Engines
          */
          FOR nI := 1 TO LEN(aDbes)
              IF ! DBELOAD( aDbes[nI][1], aDbes[nI][2])
                 Alert( aDbes[nI][1] + MSG_DBE_NOT_LOADED , {"OK"} )
              ENDIF
          NEXT nI

          /*
           *   Erzeugen von Database-Engines
          */
          FOR nI := 1 TO LEN(aBuild)
              IF ! DBEBUILD( aBuild[nI][1], aDbes[aBuild[nI][2]][1], aDbes[aBuild[nI][3]][1])
                 Alert( aBuild[nI][1] + MSG_DBE_NOT_CREATED , {"OK"} )
              ENDIF
          NEXT nI

          IF ! DbeLoad( "CDXDBE",.T. )
             Alert( "Database-Engine CDXDBE konnte nicht geladen werden!", {"OK"})
          ENDIF
          IF ! DbeBuild( "DBFCDX", "DBFDBE", "CDXDBE" )
             Alert( "DBFCDX Database-Engine konnte nicht erzeugt werden!", {"OK"})
          ENDIF
          DbeInfo(COMPONENT_DATA,DBFDBE_LIFETIME,0)
          DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED) // macht das die Massenabfertigung schneller? (29.10.2008)
          RETURN

[brandelh]

wenn ich stattdessen DbeLoad("cdxdbe") mache, dann erscheint eine Fehlermeldung das die ungültig ist. Aber in den Beispielen im Handbuch steht es so, das man es so machen kann.

der 2. Parameter in diesem Array entscheidet, ob du eine DBE direkt (also vom Programmheraus aufrufbar) laden, oder nur in einer Kombination verwenden darfst.
normalerweise werden weder DBFDBE noch CDXDBE direkt verwendet, also beide auf .t. (verstecken ?)

Code: Alles auswählen

          LOCAL aDbes := {;
                          { "DBFDBE", .T.},;
                          { "CDXDBE", .T.},;
                          { "DELDBE", .F.},;
                          { "SDFDBE", .F.};
                         }

wenn du die DBFDBE direkt laden willst, musst du diesen auf .f. ändern:

Code: Alles auswählen

          LOCAL aDbes := {;
                          { "DBFDBE", .F.},;
                          { "CDXDBE", .T.},;
                          { "DELDBE", .F.},;
                          { "SDFDBE", .F.};
                         }

ABER

Dein Problem liegt nicht innerhalb von Alaska++ sondern davor !

Solange du eine ANSI-DBF bekommst, die nicht der "Norm" entspricht, hast du Probleme !

[Manfred]

Deswegen frage ich ja ganz dumm: "Wie sieht die Norm aus"? Und danach werde ich dann den Rest aufbauen.

[Manfred]

Wenn ich in der VX Chr(213) eintippe, erscheint das € Zeichen.

Wenn ich in dem Hybridprogramm im Gui SLE ein AltGr + E eingebe, erscheint ein Strich

[AUGE_OHR]

hi,

Wenn ich in der VX Chr(213) eintippe, erscheint das € Zeichen.
Wenn ich in dem Hybridprogramm im Gui SLE ein AltGr + E eingebe, erscheint ein Strich

Das ist doch "nur" die Anzeige ... versuche doch mal ConvToOemCP( oSLE:getdata() ).

das Problem ist jetzt, dass immer wieder FoxCDX genannt wird. Ich habe aber CDXDBE im Einsatz.

du hast doch sicherlich in deiner DBESYS

Code: Alles auswählen

   IF !DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )
      ALERT( "FOXCDX Database-Engine;konnte nicht erzeugt werden", { "OK" } )
   ENDIF

FOXBDE ist die DATA-Komponente und CDXDBE die ORDER-Komponente

"Wie sieht die Norm aus"?

für Deutschland

Code: Alles auswählen

USE MyDBF VIA DBFNTX -> OEM
USE MyDBF VIA FOXCDX -> ANSI

[Manfred]

Nachdem ich jetzt eine zeit herumgewerkelt habe, ist eine weitere Frage aufgetaucht.

Ich habe jetzt alle DBF und CDX auf Ansi umgestellt, damit da schonmal Einigkeit herrscht. Wenn ich aber jetzt im reinen GUI aus einer Ansi DBF lese, dann sind die Umlaute immer noch falsch. Ich habe das Programm auf SET CHARSET ANSI gestellt. Was könnte denn dann noch falsch sein? Das richtige Ergebnis erhalte ich, wenn ich aus der DBF lese und das dann nach OEM konvertiere. Ich blicke nicht mehr durch, wann was eingestellt werden muß.

[AUGE_OHR]

Ich habe jetzt alle DBF und CDX auf Ansi umgestellt, damit da schonmal Einigkeit herrscht. Wenn ich aber jetzt im reinen GUI aus einer Ansi DBF lese, dann sind die Umlaute immer noch falsch. Ich habe das Programm auf SET CHARSET ANSI gestellt. Was könnte denn dann noch falsch sein?

hm ... dann hast du einmal "zuviel ANSI"

Das richtige Ergebnis erhalte ich, wenn ich aus der DBF lese und das dann nach OEM konvertiere. Ich blicke nicht mehr durch, wann was eingestellt werden muß.

wieso "richtig" ? womit "beurteilst" du das ?
wofür willst du den noch OEM haben ?

ich lese, per activeX, aus dem Outlook Calender der ANSI ist.
als DBE nehme ich FOXCDX ohne SET CHARSET. Damit erhalte ich , ohne irgendwelche ConvtoXXXX

FOXCDX_BROWSE.JPG (24.65 KiB) 6977 mal betrachtet

mit einem Xbase++ Browse()

FOXCDX_BRO25.JPG (30.67 KiB) 6977 mal betrachtet

mit BRO.EXE v2.5 und COMIX

ANSI_OEM.JPG (42.33 KiB) 6977 mal betrachtet

und das in meinem Calender

[Manfred]

Das Problem ist, ich lese ein Feld aus einer DBF und schaue mir das dann im Debugger an. Dort steht es dann falsch. Ich verstehe auch nicht mehr, was da abgeht. Wenn ich das dann in eine andere DBF Speicher, sind die Umlaute falsch.

[AUGE_OHR]

hi,

vielleicht solltest du dir die DBF mal mit einem HEX Editor ansehen
siehe auch http://www.xbaseforum.de/viewtopic.php? ... dbf+header
ich "denke" FOXDBF mit COMIX Einstellung sollte : DOS 850 ergeben.

[Rolf Ramacher]

Hi Manfred,

lass dir dochmal ein beispiel mit msgbox() anzeigen ohne convto?? ist hier alles klar brauchst du nichts zu machen - ansonsten umwandeln

[brandelh]

Hi,

der alte Textmodus Debugger zeigt 'ANSI' Umlaute immer falsch an, da dieser immer OEM nutzt
Genauso ein ? cAnsi ... am Besten eine msgbox(cAnsi) fragen, die weiß um was es geht ...

PS: die DBF hast du doch mit FOXCDX nach set charset to Ansi neu angelegt, oder ?