OEM-Oberfläche mit ANSI-Ausgabe

Grafische Primitive, XbaseParts und Darstellungsfragen allgemein.

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von Jan »

Hallo,

gerade stoße ich auf ein unvorhergesehenes Problem: Ich habe ein Programm, dem man optisch die Herkunft aus Clipper-Zeiten ansieht. Der Kunde besteht darauf, das die Clipper-Oberfläche bestehen bleibt. Auch wenn ich einzelne Teile auf XBParts umschreiben durfte. Die Druckausgaben sind teilweise noch per ?..., aber meist per Str...()

Jetzt konvertiere ich die DBFNTX-Datenbanken alle nach FOXCDX, und da ins ANSI-Format. Was natürlich auf Ausdrucken und auf dem Bildschirm alles korrekt dargestellt werden sollte.

Ich habe also folgende Gegebenheiten:
Quellcode ANSI (war schon immer so)
Datenbanken ANSI (voeher OEM)
SET CHARSET TO ANSI ist im Code eingetragen (vorher ohne)
Kein Compilerschalter /GA (vorher mit)

Und die Oberfläche ist - Schrott. Umlaute werden in den OEM-Bereichen falsch dargestellt. GUI-Bestandteile dagegen werden korrekt dargestellt. DbEdit() und GET werden grundsätzlich falsch dargestellt. Egal ob mit oder ohne /GA.

Ändere ich den Compilerschalter wieder auf /GA, ist die Bildschirmdarstellung im OEM-Bereich korrekt. Die Anzeige der GUI-Elemente dagegen nicht.

Interessant ist folgendes: Ich habe ohne /GA kompiliert. Gehe in das programm, und erfasse text mit einem "ü" in einem Get. Dann geht eine Maske auf mit einem DbEdit(). Der erste Satz mit einem Eintrag wie dem Get-Inhalt wird dargestellt. Das sieht dann so aus:
ANSI-Problem.jpg
ANSI-Problem.jpg (5.6 KiB) 8269 mal betrachtet
Warum aber ist das "ü" im Get eine Kubik, und im DbEdit ein tiefgestellter Block? Müsste das nicht gleich dargestellt werden?

Gibt es denn keinerlei Möglichkeit, ANSI sowohl im GUI- als auch im OEM-Bereich korrekt darzustellen? Und Codeintern auch korrekt darzustellen? Ich hab ja nun wenig Lust, überall die Ausgabe passend abfangen und eventuell mit ConvToANSICP() oder ConvToOEMCP() umzudrehen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von brandelh »

Sind die GUI Elemente nur auf neuen XbpDialog() Fenstern oder auf dem alten XbpCRT() gemischt ?

Ich habe schon ANSI Anwendungen bei der Ausgabe auf CRT Fenster mit ConvToOEMCP() nachgeholfen,
aber bei GET und MemoEdit etc. geht das ja so nicht.

Wenn die Fenster getrennt sind, sollte ein Umschalten beim Focuswechsel von OEM auf ANSI helfen, ob das aber machbar ist ?

Ich habe bisher nur OEM Anwendungen (XbpCrt()) mit XbpDialog() Fenster aufgebort, alles immer mit OEM als Zeichensatz (im Quellcode) und das hat funktioniert.

Alles was ich neue Anfange ist nur GUI oder hat keine GUI und ist in ANSI. So geht es auch.

Nach meiner Erfahrung brauchen die alten Elemente den OEM Zeichensatz !
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von Jan »

Hallo Hubert,

das ist eine Hybrid-Anwendung - OEM-Oberfläche mit ein paar eingestreuten Statics, Browses, und MLE. Alles in einem Fenster gemischt.

Das wär natürlich Murks, wenn die alten Say und Get immer OEM bräuchten. Denn die DBF sind eindeutig ANSI. SET CAHRSET TO ANSI muß also definitiv bleiben. Ich muß mal versuchen wie das wird, wenn ich /GA wieder rein nehme, und alle grafischen Ausgaben (Oberfläche, Ausdrucke) mit ConvToAnsiCP() erweitere. Das wird eine Sch...-Arbeit werden.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von Jan »

Ein paar Grundlagen-Fragen dazu:

Als ich die DBF von DBFNTX nach FOXCDX konvertiert habe, hatte ich SET CHARSET TO ANSI eingeschaltet. Lt. Tipp von Tom sollte das bewirken, das die Daten in der neuen dbf als ANSI geschrieben werden.

Wenn ich nun die ganze Applikation mit /GA kompiliere, und SET CHARSET TO ANSI wieder raus nehme, wird alles ganz korrekt angezeigt. Auch die Ausdrucke stimmen (außer das ich das € wieder von Chr(128) auf Chr(213) zurück schrauben muß). Die interne Konvertierung der Datenbankdaten funktioniert also reibungslos.

ABER: Die Daten werden doch dann garantiert wieder als ASCI in der dbf gespeichert?!? Der Hex-Editor scheint das zumindest zu bestätigen. Damit hab ich dann ja auch wieder nix gewonnen. Anzeige und Druck super, aber dbf unschön.

Dazu eine weitere Frage: Welchen ernstzunehmenden Nachteil hat es, die Daten in ASCII zu speichern? Das ist eine reine InHouse-Anwendung. Die Daten werden höchstens mal (in einer kopierten) dbf mit Excel angesehen. Sonst immer mit den Xbase++-Apps. Allerdings ist angedacht, kurzfristig auf ADS umzusteigen (daher die Konvertierung von DBFNTX nach FOXCDX, da manche dbf mehr als 20 ntx haben). Und mittel- oder langfristig nach SQL. Irgendwo zwischen ADS und SQL wird noch stellenweise CXP kommen, also rein grafische Ausgabe. Gibt das dann später Probleme, wenn ich jetzt auf ASCII bleibe?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von Koverhage »

W
elchen ernstzunehmenden Nachteil hat es, die Daten in ASCII zu speichern?
Erst mal keinen, bzw. habe noch keinen festgestellt, meine sind alle ASCII.

Warum besteht der Kunde darauf, dass die Clipper Oberfläche bleibt ?
Gruß
Klaus
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von Jan »

Hallo Klaus,

das hat mehrere Gründe. Einerseits hält er OEM-Oberflächen für produktiver für die Bediener. Andererseits ist er selber alter Clipper-Programmierer. Und möchte auch den Xbase++-Code verstehen können (er programmiert auch noch selber). Klassen versteht er nicht, also darf ich sowas nicht einsetzen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von Tom »

Hallo, Jan.

Der Compilerschalter /GA bewirkt (nur), dass im Quellcode enthaltene ANSI-Zeichen nach OEM konvertiert werden.

Schau Dir mal die Dokumentation zu SET CHARSET an. Da siehst Du, dass im Textmodus immer eine OEM-Darstellung stattfindet, sonst wäre der Textmodus auch nicht Clipper-kompatibel. Durch SET CHARSET TO ANSI vermischst Du im Hybridmodus ANSI und OEM, was zu Deiner Falschdarstellung führt.

Der Zeichensatz von Tabellen (DBFNTX - immer OEM, FOX - je nach Wunsch) spielt nur dann eine wesentliche Rolle, wenn der Darstellungszeichensatz ein anderer ist. Eine GUI-Anwendung, die mit SET CHARSET TO OEM und OEM-Tabellen arbeitet, muss alle grafischen Ausgaben konvertieren. Eine GUI-Anwendung "in ANSI" muss bei jedem Zugriff auf Tabellen Textfelder konvertieren. Ideal ist also zumindest theoretisch eine ANSI-Anwendung mit ANSI-Tabellen, aber Du hast ja den Hybridmodus. Siehe oben.
Herzlich,
Tom
DelUser01

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von DelUser01 »

Hallo Jan

Du hast vermutlich etwas ähnliches vorliegen wie das meinige System (kennst Du ja).
Ich arbeite immer noch mit

Code: Alles auswählen

Set( _SET_CHARSET    , CHARSET_OEM )
Set( _SET_COLLATION  , COLLAT_GERMAN )
Habe vor langer Zeit - vermutlich bei der Umstellung Clipper -> Xbase++ - einmal versucht das Ganze auf ANSI umzustellen. Die Daten, die Masken usw.
Wollte unter anderem auch auf CDX. Nach nicht unerheblichem Aufwand habe ich alles verworfen und mit OEM weitergemacht. Gibt eigentlich nirgends Probleme. Der einzige Aufwand ist, dass bei Kommunikation mit anderen Programmen bzw, Windows die Konvertierungen stattfinden müssen.

Code: Alles auswählen

ConvToAnsiCP()
ConvToOemCP()
Man gewöhnt sich daran das zu machen bzw. regelt das über Zentralfunktionen die für mich mitdenken.

Ich nehme an, dass es sich bei Deinem vorliegenden Programm um ein größeres Paket handelt sonst würdest Du nicht ins Schwitzen kommen bei der Umstellung.
Wenn der Kunde weiterhin mit der altbekannten Oberfläche arbeiten will würde ich Dir von einer Umstellung des CharSets abraten.

Warum willst Du das überhaupt machen? Nur wegen FoxPro?
DelUser01

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von DelUser01 »

Hallo Jan - nochmals ich
Jan hat geschrieben:Einerseits hält er OEM-Oberflächen für produktiver für die Bediener
Da meinst Du vermutlich "CRT-Oberfläche" (ANSI/OEM machen an der Oberfläche kein Unterschied - wenn ALLES richtig umgestellt ist).

So ähnlich sieht es einer meiner Kunden auch. Das ganze Büro dort "verweigern" das Arbeiten mit einem MLE-Editor und Proportionalschrift. Die benützen weiter das CRT-Fenster mit dem alten MemoEdit. Und manches andere alte Zeugs...

Aus Erfahrung kann ich dir nur raten: so lange der "Boss" dort das so will und für gut befindet kannst Du dir nur Ärger einhandeln wenn Du an der Oberfläche fummelst und die Masken, Ausgaben usw. (noch) nicht 100%ig passen...
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von brandelh »

Hallo Jan,

Die FOXDBF, die auf ANSI angelegt wurde wird immer in ANSI bleiben und auch weiter ANSI schreiben, egal wie das Anwendungsprogramm eingestellt ist.
Genauso wird eine DBFNTX immer OEM schreiben (von ein paar Tricksereien mal abgesehen) und auch dies sauber darstellen.
Ein Problem wird dann auftreten, wenn eine DBF gelöscht und neu erzeugt wird.

Ich habe GUI Anwendungen mit XbpDialog() etc. im Einsatz die OEM Zeichensatz haben, der Quellcode ist in OEM und alles sieht gut aus ... nur eines der Zeichen © ® wurde bei mir falsch dargestellt ... und es gibt Zeichen die nur Ansi kennt, aber die habe ich nicht. Eine OEM Anwendung hat also normalerweise kein Problem, insbesondere wenn du mit @ SAY arbeiten musst.

Nach der Versprechung von Alaska, dass alle Zeichen intern richtig umgesetzt werden, sollte eine ANSI EXE eigentlich auch die XbpCrt() Masken mit @ SAY und MemoEdit (also /PM=PM gelinkt) sauber darstellen (und dort eine automatische ANSI 2 OEM Konvertierung durchführen). Nach meiner Erfahrung funktioniert das aber nicht !

Nach meinen Erfahrungen ist es aber durchaus problematisch den Quellcode in ANSI zu erstellen und mit den /GA /GO Schaltern zu arbeiten - es kann aber sein, dass der Fehler bei meiner Bedienung lag. Ich jedenfalls nutze die nie, im Zweifel kodiere ich die ganzen PRGs um, dazu habe ich ein kleines Programm geschrieben ... (Meine Basisklasse wird in beiden Zeichensätzen benötigt.)

Ehrlich gesagt verstehe ich nicht warum eine @ SAY Anwendung überhaupt nach ANSI umgestellt wird, wie geschrieben ich habe GUI mit OEM Quellcode und die Umlaute stimmen immer !
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von Jan »

Moin,

vielen Dank für all die Hinweise und Vorschläge. Ich bin jetzt gerade dabei, die ganzen dbf neu nach FOXCDX zu konvertieren, dieses mal aber lasse ich es bei ASCII. Dem hatte ich offensichtlich doch zu viel Bedeutung beigemessen.

Parallel korrigiere ich alle Programme, das die wieder den SET CHARSET TO ANSI raus haben, und mit /GA kompiliert sind.

Damit sollte dann alles wieder sauber laufen. Ich melde mich, wenn ich damit durch bin, und berichte (hoffentlich kurz) wie es läuft.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
DelUser01

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von DelUser01 »

Hallo Jan
Jan hat geschrieben:...dieses mal aber lasse ich es bei ASCII
vermutlich meinst Du OEM?
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von brandelh »

ASCII ist die DIN Bezeichnung für verschiedene Codes darunter auch den den du mit OEM meinst,
ursprünglich nur 7 Bit, kamen 8 Bit Erweiterungen dazu um andere Sprachen zu unterstützen.
IBM2 wurde der 8 Bit Zeichensatz genauso genannt wie PC850 oder PC437.

ASCII meint damit eben nicht ANSI ;-)
Gruß
Hubert
DelUser01

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von DelUser01 »

Oha - muss wohl meine Brille putzen...
Habe - weil Jan vom Charset schreibt - wohl automatisch ANSI gelesen (da nicht OEM) :roll:
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von AUGE_OHR »

Jan hat geschrieben:Jetzt konvertiere ich die DBFNTX-Datenbanken alle nach FOXCDX, und da ins ANSI-Format. Was natürlich auf Ausdrucken und auf dem Bildschirm alles korrekt dargestellt werden sollte.
ich frage mich "was" es für einen Vorteil hat eine Cl*pper Anwendung auf das FOX "Pro" System umzustellen ?

Frage : hast du es schon mal mit einem anderen Font / Codepage ausser "Alaska CRT" versucht ?
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von Jan »

Jimmy,

der Vorteil ist, das der ADS mehr Indexdateien je dbf verwalten kann mit FOXCDX als mit DBFNTX. Manche dbf haben mehr als 20 ntx, und das macht der ADS nicht mit. Also ab nach FOXCDX, da ist die ANzahl unbegrenzt. Wobei ich natürlich die cdx als Container für die TAGs benutze.

Ein anderer Vorteil sind die binären Memofelder, die nur FOXDBE anbietet.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
DelUser01

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von DelUser01 »

Hallo Jan
Jan hat geschrieben:Manche dbf haben mehr als 20 ntx, und das macht der ADS nicht mit
Bisher war ich der Meinung, dass Clipper/Xbase++ max. 15 Index kann. Seit wann geht das bis 20? (ohne ADS usw.)
Ein anderer Vorteil sind die binären Memofelder, die nur FOXDBE anbietet.
Frage: Was möchtest Du in den binären Memos speichern? Bilder, DOCX, XLSX,...?
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von brandelh »

Eine CDX mit gleichem Namen wie die DBF ist auf jeden Fall auch ein Vorteil.
Dazu kommt, dass CDX Dateien komprimiert und damit kleiner sind - somit muss auch weniger durch die Leitung.
Man spart sich auch UPPER() im Indexbegriff, kann somit aber auch nicht nach "Otto" und "otto" unterscheiden. ;-)
Gruß
Hubert
DelUser01

Re: OEM-Oberfläche mit ANSI-Ausgabe

Beitrag von DelUser01 »

brandelh hat geschrieben:...dass CDX Dateien komprimiert und damit kleiner sind - somit muss auch weniger durch die Leitung
Bei den heutigen Rechner- und Netzwerkleistungen ist das eigentlich kein Argument mehr einen entsprechenden Umstellungsaufwand zu betreiben. Mit ADS erst recht nicht.
Wenn dann gleich SQL Auch wenn ich das noch nirgends gemacht habe :)
Antworten