probleme beim programmieren für koreanisches winXP...

[mgalli]

Zitat:

Zitat von dahead

aber du könntest um das zu überprüfen einfach mal ein dt. hallo-welt schreiben und das dort ausführen.

das werde ich mal versuchen...

Zitat:

Zitat von dahead

du schreibst dein programm hängt sich gleich beim start auf. wird dort irgendwas windows-relevantes ausgeführt?

nein, mein programm greift lediglich auf die odbc-connection zu, ansonsten passiert da nichts. das dort gleich die kernel32.exe einen fehler wirft wundert mich eh.

hmmm, vielleicht "disable" ich einfach mal alle mysql-abfragen beim start. das kann den fehler vielleicht darauf eingrenzen. daran hab ich, während ich verwundert in der imbiss-küche stand, gar nicht gedacht...


dann mach ich mich mal an's probieren und gewöhne mich langsam und ungern an den gedanken, dass windows wohl doch nicht gleich windows ist...


marcus


ps: der start-button ist übrigens neben den icons tatsächlich das einzige was bei der version gleich ist! der rest ähnelt eher einem display, das mit einer rasierklinge ganz fein und akkurat zerkratzt wurde... :-D

[Kedariodakon]

Zitat:

Zitat von mgalli

dann mach ich mich mal an's probieren und gewöhne mich langsam und ungern an den gedanken, dass windows wohl doch nicht gleich windows ist...

Schon alleine wenn ich an Verzeichnissstrukturen denke ;)
Denn es gibt ja auch Ordner mit Koreanischen usw... Namen...

Bye

[Bernhard Geyer]

Zitat:

Zitat von Kedariodakon

Schon alleine wenn ich an Verzeichnissstrukturen denke ;)
Denn es gibt ja auch Ordner mit Koreanischen usw... Namen...

Wenn man die entsprechenden API-Funktionen verwendet um die Systemverzeichnis zu bestimmen ist das keine Problem. Die gehen auch ohne Unicode immer auszulesen.

@mgalli: Du verwendest MySQL und greifst über ODBC darauf zu? brrrr.
Nimm lieber einen native Treiber und du hast 1000 Problem weniger: Keine BDE bzw. ADO, keine ODBC und kein MyODBC. Evtl. ist ja der MySQL-ODBC-Treiber der verursachende Teil.

[Kedariodakon]

Zitat:

Zitat von Bernhard Geyer

Wenn man die entsprechenden API-Funktionen verwendet um die Systemverzeichnis zu bestimmen ist das keine Problem. Die gehen auch ohne Unicode immer auszulesen.

Das was man da aber rausbekommt ist dooch nen Unicode String :zwinker:
Oder irre ich mich? :gruebel:

BYe

[Bernhard Geyer]

Zitat:

Zitat von Kedariodakon

Zitat:

Zitat von Bernhard Geyer

Wenn man die entsprechenden API-Funktionen verwendet um die Systemverzeichnis zu bestimmen ist das keine Problem. Die gehen auch ohne Unicode immer auszulesen.

Das was man da aber rausbekommt ist dooch nen Unicode String :zwinker:
Oder irre ich mich? :gruebel:

System-Verzeichnisse sind immer so gewählt das sie auch für nicht-Unicode-Anwendungen über die aktuelle Codepage erreichbar. Deutsche Umlaute (üöä) stellen unter einem Westeuropäischen Windows auch keine Problem dar. So ist es auch für koreanische Zeichen unter einem koreanischen Windows. Die Umwandlung Widestring -> String wird in Delphi automatisch immer mit der aktuellen Codepage durchgeführt.

[mgalli]

Zitat:

Zitat von Bernhard Geyer

@mgalli: Du verwendest MySQL und greifst über ODBC darauf zu? brrrr.
Nimm lieber einen native Treiber und du hast 1000 Problem weniger: Keine BDE bzw. ADO, keine ODBC und kein MyODBC. Evtl. ist ja der MySQL-ODBC-Treiber der verursachende Teil.

jap, genau daran scheints zu liegen. ich habe mal alle datasets und querys rausgeworfen und das mal testen lassen. dann lässt es sich starten und läuft, nur halt ohne daten... :?

ich würde gerne mal eine alternative zu myodbc testen, muss aber gestehen, dass ich nicht so wirklich weiß was du mit "nativem treiber" meinst. alles was ich bisher gemacht habe war über ado, die bde und eben odbc...

kann mir jemand einen tipp geben nach welchen begriffen ich suchen muss um darüber was zu erfahren? konnte bisher nichts wirklich aufschlussreiches finden...

ganz wunderbar wäre natürlich auch irgendein beispiel etc... :-D

danke!

marcus

[supermuckl]

stichwort mysql ohne komponenten

[Bernhard Geyer]

z.B. MySQLDAC