CDoW()

[AUGE_OHR]

Du hast Steffens Antwort in der Newsgroup gelesen und verstanden?

Wenn Du SetLocale() und GetLocalInfo() mit anderen Sprachen nutzen willst, mußt Du sicherstellen, dass Du in ANSI arbeitest
Also SET CHARSET TO ANSI und Schriftart und dessen codepage für Dein Ausgabefenster entsprechend setzen (XbpFont:CodePage)

du hast doch auch wie Steffen die Bilder gesehen ?
was meinst du auf was für einem OS() ich die gemacht habe ?

da ich die auch im Alaska Forum veröffentlicht habe "müsste" Steffen es
VOR seiner Antwort gesehen haben ... ich bin doch nicht "blöde" ...

auch steht im Source zur Demo

Code: Alles auswählen

   SET EPOCH TO YEAR( DATE() ) - 50
   SET CENTURY ON
   IF ID_CHINA
      SET DATE SYSTEM
      SET DATE FORMAT TO "mm-dd-yyyy"
   ELSE
      SET DATE GERMAN
      SET DATE FORMAT TO "dd.mm.yyyy"
   ENDIF

und was die "Schrift" angeht "denke" ich mal das die auf dem Notebook, mit "original" OS(), stimmen.

Tja das eine ist die "Theorie" und das andere die "Praxis"
"Wir" haben nun eine "praktische" Lösung die funktioniert und Steffen ein "Problem" mit seiner "Theorie" ...

[Martin Altmann]

Hallo Jimmy,
wo ist bei Dir SET CHARSET TO ANSI?
Wo hast Du XbpFont:CodePage entsprechend gesetzt?

"Wir" haben nun eine "praktische" Lösung die funktioniert und Steffen ein "Problem" mit seiner "Theorie" ...

Nicht ganz so voreilig! Bei Deinem Beispiel gibt es ja einen gravierenden Unterschied zwischen linker und rechter Spalte - und ich meine da nicht die Schmutzzeichen am Ende!

Viele Grüße,
Martin

[AUGE_OHR]

wo ist bei Dir SET CHARSET TO ANSI?

diese Aussage ist schlicht FALSCH

Wo hast Du XbpFont:CodePage entsprechend gesetzt?

genauso wie diese den beides mal wird von "deutschen" Verhäldnissen ausgegangen.... wer hat ASCI ?

ich arbeite ja auf dem Notebook mit installiertem OS(), also mit "default" ANSI und "System Codepage" so wie wir Arial verwenden würden.

Deshalb ist die DBF dann OEM und wird durch das Xbase++ GUI System -> ANSI gebracht was
man dann durch ConvToOemCP() erst wieder in das OEM Format bringen muss um es "richtig" anzuzeigen.

... ich würde auch liebend gerne eine andere "reine" ANSI Lösung daraus machen, aber das
geht NICHT mit den "üblichen" System Fonts sondern man müsste auf sowas wie ArialUNI.TTF
verwenden ...

Nicht ganz so voreilig! Bei Deinem Beispiel gibt es ja einen gravierenden Unterschied zwischen linker und rechter Spalte - und ich meine da nicht die Schmutzzeichen am Ende!

die "Schmutzzeichen" waren ein x0D und wurden ja auch in der "lates" von Günter "bereinigt".

Das "doppel" Bild ist aus dem Source d.h. "links" ist Xbase++ setLocale() NLS und "rechts"
die (alte) API Funktion welche die "richtigen" (bestätigt) Wochentage/Monate etc. anzeigen.

eine "Bestätigung" wäre wohl dann möglich wenn man den Source auf weiteren "nicht German"
OS() ausprobiert, vorzugsweise mit nicht mit lateinischen Zeichen (kyrillisch,indisch ...)

[Martin Altmann]

Hallo Jimmy,

die "Schmutzzeichen" waren ein x0D und wurden ja auch in der "lates" von Günter "bereinigt".
Das "doppel" Bild ist aus dem Source d.h. "links" ist Xbase++ setLocale() NLS und "rechts"
die (alte) API Funktion welche die "richtigen" (bestätigt) Wochentage/Monate etc. anzeigen.

darum sollst Du ja - für Deinen linken Teil - auch alles auf ANSI setzen und die codepage des Fensters entsprechend konfigurieren. Ich sehe da im Moment nämlich keinerlei Übereinstimmung bei den unteren Angaben - selbst nicht "verschobenerweise"!
Einfach zu sagen "die Aussage ist falsch", ist recht einfach - zumindest wenn man es nicht probiert und widerlegt hat!
Nimm Hilfe doch an, wenn "der Chef" sie Dir bietet - Du warst doch in Rösrath auch recht überrascht, was Steffen alles gezeigt hat, oder

Viele Grüße,
Martin

[AUGE_OHR]

darum sollst Du ja - für Deinen linken Teil - auch alles auf ANSI setzen und die codepage des Fensters entsprechend konfigurieren.

NEIN, NEIN, NEIN
du würde einen AMI doch auch nicht erzählen er soll ANSI benutzen ... was denn sonst wird er
sich denken ... ASCII ... was ist das ? das gibt es doch nur in "old Germay" ...

Ich bin im auf einem "original" OS() und benutzte die "originalen" System Fonts, da gibt es
nichts einzustellen !!!

...und warum sollte ich es überhaupt tun ? die Win API Funktion liefert mir immer das "richtige"
Ergebniss unabhängig von verwendeten OS() und Font !!!

wenn es Xbase++ mit setlocale() nicht tun sollte, wäre das einfach FALSCH !!!

Ich sehe da im Moment nämlich keinerlei Übereinstimmung bei den unteren Angaben - selbst nicht
"verschobenerweise"!

KEINE Übereinstimmung = STIMMT, weil das linke FALSCH.
... es sollte links und rechts das selbe rauskommen, aber das "linke" mit setlocale() bekommt man
NICHT auf den Stand des "rechten" Bildes ... egal was ich gemacht und probiert habe.

Einfach zu sagen "die Aussage ist falsch", ist recht einfach - zumindest wenn man es nicht probiert und widerlegt hat!

Das ist einfach Blödsinn denn natürlich habe ich das alles ausprobiert. Ich mache ja nicht das erste
Programm unter Xbase++ in chinesisch.

Nimm Hilfe doch an, wenn "der Chef" sie Dir bietet - Du warst doch in Rösrath auch recht überrascht, was Steffen alles gezeigt hat, oder

Ich denke das "Problem" von Steffen ist das es zwar "seine" Demos ausprobieren kann, aber ja keine Ahnung von chinesisch hat.

... ich "vermute" mal, das in der XppNAT "mehr" steckt (siehe auch Aussage von Steffen) und da erst der Fehler passiert.

...which enforces us to have our own set of locale definition as some type of backup

denn wenn Xbase++ "pure" GetLocalInfo() benutzen würde müsste ja das selbe rauskommen.

Ich versuche nun in Hebräisch, Kyrillisch , Indisch etc. "Vergleiche" zu bekommen um zu sehen
wie sich setlocale() dort verhält ... das wären weitere "Beweise"

[Jan]

Jimmy,

wenn Du und Steffen sich die Nettigkeiten an den Kopf werfen, dann ist das Eure Sache, die Animositäten zwischen Euch beiden sind ja schließlich hinlänglich bekannt. Aber mußt Du denn wirklich hier im Forum so mit jemandem umgehen, der in aller Freundlichkeit seine Hilfsbereitschaft angeboten hat?

Jan

[Martin Altmann]

Hallo Jimmy,
lies Dir die Antwort von Steffen im Forum durch und versuche, sie zu verstehen
Dann siehst Du auch, warum das so ist - Kompatibilität zu Clipper
Mache Deinem Xbase++-Proggi klar, dass Du ANSI nutzt, damit er intern nicht auf OEM geht! Dann sollte links das selbe rauskommen wie rechts!
Du hast die Sourcen Deines Beispielproggies - mach doch die zwei Zeilen einfach dazu und probier es erneut! Sollte doch ein leichtes sein für Dich.
Dann weißt Du Bescheid.

Viele Grüße,
Martin

[AUGE_OHR]

wenn Du und Steffen sich die Nettigkeiten an den Kopf werfen, dann ist das Eure Sache, die Animositäten zwischen Euch beiden sind ja schließlich hinlänglich bekannt. Aber mußt Du denn wirklich hier im Forum so mit jemandem umgehen, der in aller Freundlichkeit seine Hilfsbereitschaft angeboten hat?

@Martin : sorry wenn du das so empfinden solltest, ich meine das wirklich nicht "böse".

ich habe wirklich alle "erdenklichen" Kombinationen ausprobiert bevor ich einen Ton gesagt habe.
Ich habe doch z.b. die Möglichkeit "on-fly" im Browser den Font zu wechseln etc. ... ging nichts,
weil der "Inhalt" einfach falsch.

Ich muss es einfach nochmal sagen das es auf einem "original" System d.h. in der "Muttersprache"
NICHT notwendig ist "irgendwas" einzustellen, wenn es um die "Darstellung" des Systemdatum
bzw Tag/Monat geht. Jede Windows Version hat den Taschenrechner und die Datum Einstellung
und die laufen "immer" mit den System Einstellungen/Font etc.

Ich kann zwar auch auf einem "German" OS() chinesiche Zeichen darstellen, und dafür brauche
ich UniCode als Font und die "richtige" Codepage, aber davon rede ich ja nicht.

Ich bin ja auf dem chinesischen OS() und habe DATE SYSTEM und "mm-dd-yyyy", also nichts
mit ANSI oder FONT/Codepage notwendig !!!





was Steffen angeht : Was zwischen mir und Steffen (angeblich) ist, hat doch nicht mit dem Thema
zu tun. Vielmehr geht es um die Tatsache das man längst nicht alles was Steffen sagt als "Gold"
betrachten sollte sondern seinen eignen Verstand nutzen sollte.

Es mag ja sein das Steffen mit seiner Art bei "unbedarften" Xbase++ User einen Effekt erzielt
das "die" an seinen Lippen hängen, aber wir wissen ja selbst alle "wie" genau man bestimmte
Aussagen (z.b. Termine) vertauen darf.

wenn ich sauer bin, dann auf Xbase++ = Alaska = Steffen, weil CDOW() nicht funktionierte.
Das aus der Sache nun sowas geworden ist konnte ich am Anfang nicht wissen ...
manch einer hätte sich ja mit einem 7Day Workaround leicht helfen können...

sieht man sich aber mit dem LocaleExplorer (Empfehlung von Günter) an was es alles gibt, so
denke ich das Alaska damals wohl nicht alle jetzigen Daten in die XppNAT eingearbeitet hat.
... ich glaube nicht das seit Version 1.0 an der Stelle "erweitert" wurde ... warum auch hat sich
ja bisher keiner beschwert das dort ein BUG vorliegt ...
wie soll ein "Deutscher" auf einem "deutschen" OS() den BUG den finden können ... ?
(2-stelliger LOCALE_ICOUNTRY wäre "zu simple", DBCS und UniCode wohl eher das Problem)

Ich denke aber das hier ein "grösseres" Problem vorliegt, nicht unbedingt "technisch" sondern in
den Köpfen der 3 Jungs von Alaska ... zu "deutsch" ... bitte worldwide denken !!!

ich habe nun an Pritpal (Indien) und Serge (Russland) jeweils eine Mail geschickt das die doch
bitte mal setLocale() vs. GetLocaleInfo() auf ihren OS() zu vergleichen ... ohne ihr OS() "um-zu-
konfiguieren" ... mal sehen was da rauskommt.

[Günter Beyes]

Jimmy,

überprüfe mal auf dem chinesischen PC die Regions- und Sprachoptionen.
Auf der Tab-Page "Regionale Einstellungen" sollte Chinesisch (Taiwan) ausgewählt sein. Auf der Tab-Page "Erweitert" auch
Damit wird die Sprachunterstützung für Nicht-Unicode-Anwendungen aktiviert, worunter wir ja wohl auch fallen.
Mit diesen Einstellungen funktioniert das auf meinem deutschen XP-System prächtig, siehe Anhang.

Gruss
Günter

Taiwan.rar

(140.63 KiB) 203-mal heruntergeladen

[AUGE_OHR]

Mache Deinem Xbase++-Proggi klar, dass Du ANSI nutzt, damit er intern nicht auf OEM geht! Dann sollte links das selbe rauskommen wie rechts!

vielen Danke für deine Hilfe (Ernst gemeint), aber das ist es wirklich nicht.

ich bin auf dem ACER Notebook, frisch ab Werk mit "original" OS() ... sozusagen vom Fliessband
alles auf dem Notebook ist chinesisch ... naja die Tastatur habe ich ausgetauscht
ich rede also NICHT von einem "deutschen" OS() ... das ist ein anderes Thema.

Einem Datum ist es egal ob ANSI oder ASCI oder COLLATION, es ist immer "ein" Datum, richtig ?
Die "Anzeige" des Datum stelle ich mit SET DATE SYSTEM und dem Format mm-dd-yy ein, richtig ?

DOW() gibt immer, egal auf welchem OS(), eine Nummer 1-7 zurück wobei der erste Wochentag
variieren kann, richtig ?
CDOW() "sollte" , "wenn immer möglich auf die API zugreifen", und liefert einen String des Wochentag, richtig ?

Diesen String kann man, auf dem entsprechenden OS(), IMMER mit den "System-Font-Codepage"
anzeigen, also in der "Muttersprache" !!!

dies funktioniert mit "allen System-Fonts" (Arial,Courier,Times Roman etc) des entsprechenden OS() !!!

deshalb steht es für mich fest das es keine Frage der "Darstellung" ist sondern der "Inhalt" einfach
nur "Qautsch" enthält = BUG ... DBCS / UniCode Probleme ... ?

[AUGE_OHR]

überprüfe mal auf dem chinesischen PC die Regions- und Sprachoptionen.
Auf der Tab-Page "Regionale Einstellungen" sollte Chinesisch (Taiwan) ausgewählt sein. Auf der Tab-Page "Erweitert" auch
Damit wird die Sprachunterstützung für Nicht-Unicode-Anwendungen aktiviert, worunter wir ja wohl auch fallen.
Mit diesen Einstellungen funktioniert das auf meinem deutschen XP-System prächtig, siehe Anhang.

YUP sieht gut aus. Nun wissen wir das es auch auf einem "deutschen" System funktioniert.

ich habe aber, wie ich auch Martin schrieb, das Problem auf dem "chinesischen" System, also dem
ACER Notebook (made in Taiwan). Ich habe in "so" bekommen ... direkt vom Fliessband ... d.h. ich
habe das OS() nicht selbst installiert sodas alles auf "default" (Taiwan) stehen müsste ...

ich werde nach deinem Hinweis es nochmal kontrollieren (lassen) ob es da für Xbase++ setLocate() "was-zu-holen" gibt.

... aber ich habe ja GetLocaleInfo() und das funktioniert, Danke