Euro-Zeichen [Erledigt]

Beitrag von **Dieter** » Fr, 06. Nov 2009 15:09

Hallo,

Bei der Erstellung einer Druckliste mit Hubert´s HBPrinter-Klasse habe ich es
nicht geschafft das Euro-Symbol aufs Papier zu bringen. Natürlich habe ich
festgestellt, dass dieses Problem hier im Forum schon öfter vorgekommen ist.
Die Lösung des Problems sollte eigentlich mit folgenden Einträgen in der
main() erfolgen:

Code: Alles auswählen

SetLocale( NLS_SCURRENCY, Chr(213) )
SetLocale( NLS_ICURRENCYEURO, "1" )     // EURO anzeigen

Als Schrift habe ich "10.Courier New" gewählt, da ich im Forum gelesen habe,
dass diese das Euro-Zeichen enthält. Es wird aber immer ein "_" statt dem
€-Zeichen gedruckt.
In den nationalen Einstellungen von Windows steht das Währungssymbol auf €.
Außerdem habe ich überprüft, ob ich das €-Symbol auf den Bildschirm der
Anwendung bekomme (xbase 1.90.331 ohne Zusätze mit GUI=YES). Habe Tests
gemacht in xbpdlg- und xbpcrt-Fenstern.
Ergebnis: "_" statt "€"

Bin momentan ratlos

, aber vielleicht habt ihr eine Idee ???

Beitrag von **Martin Altmann** » Fr, 06. Nov 2009 18:20

Moin Dieter,
habe ich

Kommt auf Deine Einstellung ANSI/ASCII an!
CHR( 213 ) gilt nur bei ASCII (OEM).
Bei ANSI gilt CHR( 128 ).

Viele Grüße,
Martin

Beitrag von **brandelh** » Fr, 06. Nov 2009 18:48

Hallo,

wenn ich dich Recht verstehe, hast du im gesamten Programm das Europroblem oder nur bei HBPrinter() ?

Wie ist denn deine SET CHARSET Einstellung ?
Wenn ich im Quelltexteditor (OEM) das Euro Symbol eingeben will, sehe ich immer ein "_" bei Ansi ein schwarzes Kästchen.
In meinen Programmen habe ich bisher vermieden ein Eurosymbol einzuprogrammieren, aber ich meine in einem Test mit
SET CHARSET ANSI und chr() Angabe habe ich es schon erfolgreich gemacht.

Während der Programmausführung habe keine Probleme das Eurozeichen in @ SAY GET Feldern einzugeben und zu drucken.
Auch in dem GUI Programm habe ich es eben probiert und es ging. Jeweils auch mit Ausdruck !

Beitrag von **Dieter** » Fr, 06. Nov 2009 20:33

Hallo Martin,
Hallo Hubert,

@Martin
SET CHARSET TO OEM
Diese Einstellung habe ich aus Kompatibilitätsgründen (Clipper-DBFs) vorgenommen.
Also ist die SetLocale-Einstellung mit chr(213) doch wohl richtig.

@Hubert
Mein Quelltexteditor (Multi-Edit) ist auf ANSI eingestellt. Deshalb habe ich deine ANSI-Version von HBPrinter installiert.
Alle Umlaute die ich in ME eingebe werden richtig dargestellt.
Warum das blöde Euro-Zeichen nicht gedruckt und angezeigt wird, kann ich nicht nachvollziehen.
Übrigens ist die neue Druckliste, die ich mit Hilfe deiner Druckerklasse erstellt habe, wirklich gut gelungen. Sieht auch ohne
€-Zeichen gut aus. Die Erstellung der Liste ging schneller voran, als das endlose Probieren mit dem verflixten €.

Beitrag von **Martin Altmann** » Fr, 06. Nov 2009 20:40

Hallo Dieter,
sollte dann stimmen!
Es sei denn, Du arbeitest explizit mit ConvToAnsiCP() und vergisst dabei, das Euro-Zeichen mit zu konvertieren...
Ich sehe gerade, Du schreibst in einem ANSI-Editor OEM-Zeichen? Das kann nur Probleme geben!
Wenn ANSI, dann durchgehend! Gleiches gilt natürlich auch umgekehrt!

Viele Grüße,
Martin

Beitrag von **Dieter** » Fr, 06. Nov 2009 21:06

Hallo Martin,

ich schreibe mit meinem Editor natürlich ANSI-Zeichen. Aber wenn ich dich richtig verstehe, dann müsste ich,
wenn ich mit einem ANSI-Editor programmiere auch SET CHARSET TO ANSI einstellen. Muß ich dann nicht auch
meine Datenbanken nach ANSI konvertieren?

Beitrag von **Martin Altmann** » Fr, 06. Nov 2009 21:17

Genau!
Und aus diesem Grunde solltest Du lieber Deinen Editor auf ASCII (OEM) einstellen.
Dann hast Du diese Probleme nicht.
Ich habe bei mir den OEM eingestellt, nutze das Euro als CHR( 213 ), habe meinen Editor auf DOS (OEM) und setze meine Ausgaben ohne ConvToAnsiCP().
Bsp. (waehrung ist bei mir CHR( 213 )):

Code: Alles auswählen

GraStringAt( oPS, { eo + 50, pb }, "(" + alltrim( transform( sonder, "@E ###.##" ) + " " + waehrung ) + ")" )
::Static12:SetCaption( transform( 0, "@E 999,999.99" ) + " " + waehrung )

Viele Grüße,
Martin

Beitrag von **brandelh** » Sa, 07. Nov 2009 4:33

Hallo,

auf jeden Fall gibt es im Programm nur entweder oder !

Also entweder ANSI oder OEM - somit hättest du die OEM Version integrieren sollen

allerdings ist das nur dann wichtig, wenn man deutsche Umlaute im Beispieltext verwendet ... du brauchst also nichts ändern.

Ich habe die Erfahrung gemacht, dass es am Besten ist GUI-Programme in ANSI zu programmieren,
SET CHARSET ANSI zu verwenden und keine Compilerschalter zur Konvertierung zu nutzen.
DBFDBE etc. wird dann intern umsetzen, was meist (nur exotische Zeichen nicht) gut geht.
Die FOXDBE wird dann komplett ANSI verwenden, wenn die Datei neu erzeugt wird.

Beitrag von **Dieter** » Sa, 07. Nov 2009 16:03

Hallo,

Bei der Umstellung auf GUI habe ich mich direkt für das Programmieren im
ANSI-Modus entschieden und alle Umlaute im Quellcode geändert. Die Darstellung
aller deutschen Umlaute im Quellcode und auf dem Bildschirm klappt
hervorragend (mit Charset auf OEM). Alle Umlaute in den xbpdlg- und auch in
den xbpcrt-Fenstern werden richtig angezeigt. Wenn ich jetzt aber SET CHARSET
TO ANSI eingebe, dann werden alle Umlaute in den xbpcrt-Fenstern falsch
angezeigt.
Was soll ich jetzt tun?

1. Auf das Euro-Zeichen verzichten, da mit meinen Einstellungen ansonsten keine
Probleme bei der Darstellung der Umlaute auftauchen?

2. Den Editor wieder auf OEM einstellen, wie es Martin macht und
alle deutschen Umlaute neu schreiben?

3. Den Editor auf ANSI belassen, wie es Hubert bei GUI macht, den CHARSET auf
ANSI einstellen und alle Umlaute die in xbpcrt-Fenstern liegen neu schreiben?
Alle DBFNTX-Datenbanken müssten dann wohl nach ANSI konvertiert werden, weil
die Darstellung von Datenbankfeldern ansonsten in xbpcrt-Fenstern nicht funktioniert.

4. Wie Punkt 3 aber alle xbpcrt-Fenster in xbpdlg-Fenster umwandeln?

Punkt 4 ist aus Zeitgründen leider nicht schnell umsetzbar.

Was soll ich also tun????

Beitrag von **Martin Altmann** » Sa, 07. Nov 2009 16:17

Hallo Dieter,
nimm doch einfach mal (spaßeshalber) chr( 128 ) für das Eurosymbol - was passiert dann?

Viele Grüße,
Martin

Beitrag von **Dieter** » Sa, 07. Nov 2009 16:39

Hallo Martin,

hab ich gerade ausprobiert. Weder im xbpcrt- noch im xbpdlg-Fenster kommt durch chr(128) das €-Zeichen.
Verabschiede mich jetzt, da wir zum Essen eingeladen sind.
Schönes Wochenende und

Beitrag von **brandelh** » So, 08. Nov 2009 3:47

Dieter hat geschrieben:Bei der Umstellung auf GUI habe ich mich direkt für das Programmieren im
ANSI-Modus entschieden und alle Umlaute im Quellcode geändert. Die Darstellung
aller deutschen Umlaute im Quellcode und auf dem Bildschirm klappt
hervorragend (mit Charset auf OEM).

dann musst du den Compilerschalter /GO gesetzt haben. (ANSI Quellcode Literale -> OEM Programm).

Dieter hat geschrieben: 1. Auf das Euro-Zeichen verzichten, da mit meinen Einstellungen ansonsten keine
Probleme bei der Darstellung der Umlaute auftauchen?

Ich verwende in meinen Programmen immer EUR - auch deshalb, weil nicht alle Drucker
€ unterstützten und Einige die Schriften durch Eigene ersetzten.
Mittlerweile sollte sich das erledigt haben ... aber warum sollte ich umschreiben

Dieter hat geschrieben: 2. Den Editor wieder auf OEM einstellen, wie es Martin macht und
alle deutschen Umlaute neu schreiben?

Mein MED Editor bietet mir die Umsetzung an. Oder ein einfaches Programm mit memoread(), ConvToOemCP() / oder Ansi, schreiben ...

Dieter hat geschrieben: 3. Den Editor auf ANSI belassen, wie es Hubert bei GUI macht, den CHARSET auf
ANSI einstellen und alle Umlaute die in xbpcrt-Fenstern liegen neu schreiben?
Alle DBFNTX-Datenbanken müssten dann wohl nach ANSI konvertiert werden, weil
die Darstellung von Datenbankfeldern ansonsten in xbpcrt-Fenstern nicht funktioniert.

die DBFDBE und DBFNTX sind immer in OEM, die Konvertierung geht automatisch.
Wenn du hier konvertierst, ist es einmal zuviel

Dieter hat geschrieben:4. Wie Punkt 3 aber alle xbpcrt-Fenster in xbpdlg-Fenster umwandeln?
Punkt 4 ist aus Zeitgründen leider nicht schnell umsetzbar.

GUI und XbpCrt funktionieren beide !

Beitrag von **AUGE_OHR** » So, 08. Nov 2009 6:24

Dieter hat geschrieben:Weder im xbpcrt- noch im xbpdlg-Fenster kommt durch chr(128) das €-Zeichen

XbpCRT verwendet default "ALASKA CRT" als Font und da bekommst du es mit CHR(213), wenn du

Code: Alles auswählen

SETLOCALE( NLS_ICURRENCYEURO, "1" ) 
SETLOCALE( NLS_SCURRENCY, CHR( 213 ) )

gesetzt hattest.

ansonsten schau dir doch mal C:\ALASKA\XPPW32\SOURCE\samples\basics\FONT\FONTDB.EXE an
und modifiziere es um das € Zeichen anzuzeigen

Beitrag von **Dieter** » Mo, 09. Nov 2009 13:06

Hallo Hubert,

Hubert hat geschrieben:

dann musst du den Compilerschalter /GO gesetzt haben. (ANSI Quellcode Literale -> OEM Programm).

Du hast Recht, ich habe den Compilerschalter /GA gesetzt. Dies scheint auch die Ursache zu sein, warum das €-Zeichen nicht angezeigt wird.
Konvertiere ich den Quellcode von ASCI zurück nach OEM und lösche den Compilerschalter /GA, dann habe ich das €-Zeichen.

Hubert hat geschrieben:

die DBFDBE und DBFNTX sind immer in OEM, die Konvertierung geht automatisch.
Wenn du hier konvertierst, ist es einmal zuviel

Die DBFDBE kann auch das ANSI-Format verwenden, so steht es in der Alaska-Dokumentation:

DBFDBE_ANSI a .F. L Ist die Einstellung .T., wird für

DBF/DBT-Dateien das ANSI-Format verwendet

Ich werde wohl weiterhin den Editor im ANSI-Modus betreiben und vorerst den Compilerschalter /GA verwenden. Das €-Zeichen habe ich dann zwar nicht mehr, aber ich weiß jetzt auch warum das so ist. Kurzfristig könnte man ja alle Datenbanken nach ANSI konvertieren. Wenn man das in Angriff nimmt, könnte man direkt auch auf DBFCDX umstellen. Bin mir aber noch nicht sicher, ob ich das so umsetzen soll.

Beitrag von **brandelh** » Mo, 09. Nov 2009 13:50

Dieter hat geschrieben:Hallo Hubert,
Hubert hat geschrieben:
dann musst du den Compilerschalter /GO gesetzt haben. (ANSI Quellcode Literale -> OEM Programm).
Du hast Recht, ich habe den Compilerschalter /GA gesetzt. Dies scheint auch die Ursache zu sein, warum das €-Zeichen nicht angezeigt wird.
Konvertiere ich den Quellcode von ASCI zurück nach OEM und lösche den Compilerschalter /GA, dann habe ich das €-Zeichen.

Du hast Recht, ich habe die Schalter verwechselt, vermutlich ist das nachträglich "eingeflickte" € Zeichen nicht sauber in
der API Funktion eingepflegt worden, die das umsetzen soll, aber wenn du zur Laufzeit das richtige chr() Zeichen benutzt, müsste es dennoch gehen.

Beitrag von **Dieter** » Mo, 09. Nov 2009 16:06

Hallo Hubert,

du hast geschrieben:

wenn du zur Laufzeit das richtige chr() Zeichen benutzt, müsste es dennoch gehen.

Du hast vollkommen Recht!
Ich habe immer mit "€" statt CHR(213) kodiert und nicht mehr an den Kompilerschalter /ga gedacht.
Dadurch wurde immer das "_" gedruckt. Jetzt ist alles klar und das Thema ist für mich erledigt.
Vielen Dank an alle, die versucht haben mir zu helfen.

Beitrag von **brandelh** » Mo, 09. Nov 2009 17:28

Hi,

einen Tipp möchte ich noch loswerden

verwende nicht direkt chr(xyz) sondern eine Variable (wie Martin) oder einen #DEFINE oder eine Funktion().
Das macht es besser lesbar und du kannst schnell von OEM auf ANSI wechseln

z.B.

Code: Alles auswählen

#define CRLF         chr(13)+chr(10)
#define ZEI_EUR    chr(???)

oder

Code: Alles auswählen

function Währung(cID)
    do case
        case "EUR"
               if Set(_SET_CHARSET) == ??? 
                  cID := chr(???) 
               else
    ...
return cID

so bleibt man flexibler

Inoffizielles deutsches Xbase-Forum