Textfeld Umlaute stimmen nicht

[Alfred]

Hallo,

ich verwende für meine Tests eine dbf die von foxpro 2.6 erzeugt wurde.

Wenn ich nun den enthaltenen Text einem oxbpStatic zuweise, dann
erhalte ich z.B. für München M³nchen.

Gruß
Alfred

[Martin Altmann]

Hallo Alfred,
weise nicht den Inhalt des Feldes zu, sondern ConvToAnsiCP( Feld ) (oder ConvToOemCP( Feld ) - je nach eingestellter Codepage...)

Viele Grüße,
Martin

[Tom]

Hallo, Alfred.

Wie lautet Deine SET CHARSET TO-Einstellung (ANSI oder OEM)? Mit welchen Zeichensatzeinstellungen ist die Datenbank gespeichert? Was geschieht, wenn Du oStatic:SetCaption(db->text) gegen oStatic:SetCaption(ConvToAnsiCP(db->text)) oder oStatic:SetCaption(ConvToOemCP(db->text)) austauschst?

[Alfred]

Hallo Tom,

irgend etwas scheint da bei meinen Einstellungen nicht zu stimmen.

Laut meinem Hexeditor stehen für Ä Ö Ü ä ö ü

C4 D6 DC E4 F6 FC

in der dbf.

Somit laut der Alaska-Hilfe ANSI.

Hier meine Testergebnisse:

1) Inhalt des db->Feldes zuweisen:
führt ohne Set, mit SET CHARSET TO ANSI oder OEM
zu -I_Ö:³

2) ConvToAnsiCP(db->Feld)
ohne Set --_§ ! 5. Zeichen nicht darstellbar
Set ANSI --_§ ! 5. Zeichen nicht darstellbar
set OEM --_§ ! 5. Zeichen nicht darstellbar

3) ConvToOemCP(db->Feld)
ohne Set ÄÖÜäöü
Set ANSI --_§ ! 5. Zeichen nicht darstellbar
Set OEM ÄÖUäöü

Das Zeichen & (z.B. Huber & Partner) geht leider bei 3) nicht.

Welchen SET CHARSET sollte man den normalerweise(hier Windows
XP Pro) verwenden?.

Mag gar nicht darüber nachdenken was die Anwendung später in die Datenbank schreibt.

Gruß
Alfred

[Martin Altmann]

Hallo Alfred,
3 ist in Deinem Fall richtig!
Bedenke bitte, dass & als Shortcut-Identifier gilt - das nachfolgende Zeichen wird unterstrichen!
Du musst also - wenn Du ein & im Static darstellen willst, unbedingt && nehmen! Also in Deinem Fall:

Code: Alles auswählen

ConvToOemCP( strtran( db->Feld, "&", "&&" ) )

Viele Grüße,
Martin

[AUGE_OHR]

hi,

ich verwende für meine Tests eine dbf die von foxpro 2.6 erzeugt wurde.

zeig uns doch mal deine DBESYS.PRG

gruss by OHR
Jimmy

[Alfred]

Hallo Jimmy,

Code: Alles auswählen

#define MSG_DBE_NOT_LOADED   " Database-Engine nicht geladen"
#define MSG_DBE_NOT_CREATED  " Database-Engine;konnte nicht erzeugt werden"

PROCEDURE dbeSys()
LOCAL aDbes := { { "DBFDBE", .T.},;
                 { "NTXDBE", .T.},;
                 { "DELDBE", .F.},;
                 { "SDFDBE", .F.} }
LOCAL aBuild :={ { "DBFNTX", 1, 2 } } 
LOCAL i

SET COLLATION TO GERMAN
SET DATE TO GERMAN

FOR i:= 1 TO len(aDbes)
  IF ! DbeLoad( aDbes[i][1], aDbes[i][2])
     Alert( aDbes[i][1] + MSG_DBE_NOT_LOADED , {"OK"} )
  ENDIF
NEXT i

FOR i:= 1 TO len(aBuild)
   IF ! DbeBuild( aBuild[i][1], aDbes[aBuild[i][2]][1], aDbes[aBuild[i][3]][1])
     Alert( aBuild[i][1] + MSG_DBE_NOT_CREATED , {"OK"} )
   ENDIF
NEXT i             
RETURN

Gruß Alfred

[AUGE_OHR]

hi,

1.) ich sehe keine FOXDBE
2.) ich sehe : SET COLLATION TO GERMAN
3.) für FOX v2.6 muss man auch FOXDBE_CREATE_2X setzten
4.) wenn du es im Netzwerk bentzen will : FOXDBE_LOCKMODE_2X

nachzulesen im Help file unter : FOXDBE (DATA-Komponente)

gruss by OHR
Jimmy

[Alfred]

Hallo Martin,

Code: Alles auswählen

ConvToOemCP(strtran(db->Feld, "&", "&&"))

danke, dass funktioniert prima

Gruß Alfred

[Martin Altmann]

Hallo Alfred,
gerne. Das gleiche kann Dir (glaube ich) auch bei ~ passieren.

Viele Grüße,
Martin

[Alfred]

Hallo Jimmy,

vielen Dank für deine Hinweise.

Wenn ich dass alles so lese kommen mir folgende Gedanken:

Mein Ziel ist es eigentlich eine Anwendung zu schaffen, die auch noch unter
den nächsten Betriebssystemgenerationen läuft, vorausgesetzt Alasaka ist
dafür verfügbar.

Macht es dann nicht mehr Sinn, wenn ich die Daten in Foxpro als CSV
exportiere und diese dann in eine neu angelegte xbase++ Datei importiere?

Gruß
Alfred

[Rolf Ramacher]

Hallo Alfred,

also Foxpro kannst du weiterhin bearbeiten. und unter Vista 64-bit laufen
xbase-Programme auch. Ich würde das so lassen wie es jetzt ist.

Wer weiß denn schon was Bill Gates und Steve Balmer in Zukunft noch alles einfallen wird.

[Jan]

Steffen hat mal verlautbart, daß Xbase++ für 64Bit vorbereitet ist. Keine Ahnung, wie aufwändig das wäre dahin wirklich umzubauen.

Microsoft hat offiziell verlautbart, VFP definitiv NICHT auf 64 Bit und NICHT auf .Net umzubauen. Die Entwicklung ist auch nicht mehr in MS-Hand sondern extern. Angeblich wird es nach der aktuellen Version 9 auch keine neue mehr geben, aber ob das stimmt wage ich mal zu bezweifeln. Wenn das jetzt schon extern weiterentwickelt wird, dann könnte MS das denen ja vielleicht komplett übergeben. Da lasse ich mich mal überraschen.

Jan