Unicode Compiler Option

[EWeiss]

Zitat:

Zitat von mkinzler

Interessant ist nur, dass der Compiler eigentlich seit D8 unicodefähig ist.

Also wenn du zufällig ein koreanisches System zu hause rumstehen hast oder Rusisch (was auch immer)
Schick dir gern den Quelltext zum testen zu.

Seltsam ist das schon das ganze.

gruss Emil

[EWeiss]

Zitat:

Bitte? VB verwendet intern ausschließlich Unicode, nur ist BSTR halt ein indexierter Typ. Es ist aber gar kein Problem, daraus für die Parameterübergabe einen "handelsüblichen" Widestring zu machen.

String 10 Bytes Bis zu 2 Milliarden beliebige ASCII-Zeichen

Zitat:

Wenn Du mir die beiden Exen mal zukommen lassen kannst, zeig ich Dir im Detail wo es klemmt

kann ich machen..
Nur die EXE laufen nicht ohne Bass.dll und BassVis

Zitat:

Ich empfehle dringend, entweder zwei Varianten zu bauen (Ansi/Unicode) oder explizit nur eine der Varianten (vorzugsweise Unicode sonst gibts wieder Ärger) zuzulassen.

Habe ich schon dran gedacht :)
Es gibt eine auswahlmöglichkeit.
Zusätzlich noch eine andere den BitmapFont zu verwenden.

gruss Emil

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

Interessant ist nur, dass der Compiler eigentlich seit D8 unicodefähig ist.

Wir haben hier wunderbar mit D6 Unicodefähige (dank ElPack) Apps seit 2002.
Da ich noch nicht einen vollständigen Test mit D2007 erledigt habe vermute ich eher ein internen Handlingfehler mit PChar/PWideChar/String/AnsiString.

[EWeiss]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von mkinzler

Interessant ist nur, dass der Compiler eigentlich seit D8 unicodefähig ist.

Wir haben hier wunderbar mit D6 Unicodefähige (dank ElPack) Apps seit 2002.
Da ich noch nicht einen vollständigen Test mit D2007 erledigt habe vermute ich eher ein internen Handlingfehler mit PChar/PWideChar/String/AnsiString.

Habe es auf verschiedener weise versucht.
Mit internas von Delphi, mit der CodePage funktion der TextSuite selbst
und mit der von mir zusammengeschusterten version.

hmmm.........

gruss Emil

[Bernhard Geyer]

Und letzter großes Problem war das wird per API-Funktion mit der CP1252-Codepage einen UTF8-Text welcher in einem Widestring gelegen ist in einen Ansi-String kopieren mussten. Da manche Russische Rechner "optimiert" wurden das bei CP1252 die Russische Codepage verwendet wurde hat das unser UTF8-String nicht überlebt. Mußten dann die Codepagewandlung mit Delphi-Mitteln erledigen.

Kannst du das Problem mit einer VM-Ware-Installation nachvollziehen?

[EWeiss]

Zitat:

Zitat von Bernhard Geyer

Und letzter großes Problem war das wird per API-Funktion mit der CP1252-Codepage einen UTF8-Text welcher in einem Widestring gelegen ist in einen Ansi-String kopieren mussten. Da manche Russische Rechner "optimiert" wurden das bei CP1252 die Russische Codepage verwendet wurde hat das unser UTF8-String nicht überlebt. Mußten dann die Codepagewandlung mit Delphi-Mitteln erledigen.

Kannst du das Problem mit einer VM-Ware-Installation nachvollziehen?

Leider nein
Habe jetzt nochmal die bassplay und vis_BassVis mit D2006 compiliert
aber es wird nicht richtig bei ihm angezeigt .. weiß da keinen rat mehr.

Mal gehts mal nicht.
Kann das wohl so nicht lösen.

EDIT:
Ist ja kein geheimnis wenn da wirklich jemand interesse hat bei dem problem zu helfen
lade ich den Quelltext hoch das wäre das kleinste problem.
das andere ist alles nur ein Ratespiel(zumindest für mich)

gruss Emil

[Lossy eX]

Du musst für die Unicode Unterstützung auch wirklich komplett Unicode verwenden. Wenn du auch nur eine einzige Stelle hast an denen du kein Unicode benutzt, dann bringt das nix.

Zitat:

Zitat von EWeiss

Zitat:

Zitat von mkinzler

Versuchs es mal mit PWideChar

So wie lossy mir das erklärt hat würde das nichts bringen
Wenn die Applikation einen string schickt dann ist der Unicode Part innerhalb des strings schon gebrochen
was bedeutet das er nicht mehr UniCode fähig ist.
Also muss ihn auf jedenfall selbst wieder ins Unicodeformat konvertieren
Das funktioniert ja auch ohne probleme.

Um da etwas ins Detail zu gehen. Wenn du mit FindFirst und FindNext arbeitest hast du schon verlohren. Denn dann bekommst du nur Strings. Und diese Strings sind lokalisiert. Also ANSI mit einer Codepage. Alle Zeichen die nicht in der Codepage enthalten sind nicht vorhanden bzw ein Fragezeichen. Anstelle dieser Funktionen müsstest du dann FindFirstW und FindNextW aus der Windows Api benutzen. Dann bekommst du echte WideStrings und die kannst du dann auch als pWideChar an die TextSuite übergeben (die passende WideMethode versteht sich). Aber du musst dann wirklich überall mit WideStrings arbeiten.

Alternativ zu WideStrings würden auch UTF8 kodierte Strings gehen. Die würden beim Zuweisen auf Strings nicht beschädigt werden. Aber das Kodieren und Dekodieren ist aufwändiger. Bzw die Wide Funktionen der Win API arbeiten normal über WideStrings.

Wenn die Zeichen nie vorgelegen haben, dann werden sie auch nie wieder reingerechnet werden können. Und dann ist es egal ob du das selber machst oder nicht. Das geht nicht. Du darfst wirklich strikt nur mit WideStrings arbeiten. Ansonst hast du evtl. ein paar Unicodezeichen. Aber auch nur die die sich innerhalb der Codepage befinden.

Da String und WideString Zuweisungskompatibel sind geht es leider sehr sehr schnell, dass man sich vorhandene WideStrings zerschießt.

[Bernhard Geyer]

Zitat:

Zitat von EWeiss

Kannst du das Problem mit einer VM-Ware-Installation nachvollziehen?

Leider nein[/quote]
Dann könnte es an einer verhunzten ("Optimierten") Installation liegen

Zitat:

Zitat von EWeiss

Habe jetzt nochmal die bassplay und vis_BassVis mit D2006 compiliert
aber es wird nicht richtig bei ihm angezeigt .. weiß da keinen rat mehr.

Mal gehts mal nicht.
Kann das wohl so nicht lösen.

?? Das hast du aber am anfang nicht gesagt das es ab und zu funktioniert. Dann würde ich hier eher auf einen Programmierfehler tippen da ein Widechar-Zeichen 2 Byte sind aber u.U. nur mit 1 Byte längenangabe (Speicherreservierung?) gearbeitet wird. Läuft dein Programm mit FastMM um dieses Problem auszuschließen?

[EWeiss]

Zitat:

Läuft dein Programm mit FastMM um dieses Problem auszuschließen?

Nein benutze ich nicht.

EDIT:

@Lossy

Zitat:

Da String und WideString Zuweisungskompatibel sind geht es leider sehr sehr schnell, dass man sich vorhandene WideStrings zerschießt.

Das problem fängt doch dann schon an was der Anwender aus seiner Applikation übergibt.
Habe da keinen einfluss drauf.
Kann das ganze nochmal ganz pingelig genau überprüfen.
Aber auch dann würde wenn die Anwendung einen string anstelle eines widestring schickt es auch nicht funktionieren
Frage mich nur wie andere das machen.. wenn sie die gleichen vorraussetzungen vorfinden.

gruss Emil

[Lossy eX]

Also für Oberflächeelemente darfst du dann natürlich keine VCL Komponenten mehr benutzen. Sondern dann auf die TNTs oder ähnliche umstellen. Wenn dann ein Text eingegeben würde, dann würdest du einen passenden WideString bekommen.

String und WideString: Wenn "die Anwendung" nur einen Ansi String schickt, dann kann niemand verlangen, dass Unicode richtig unterstützt wird. Genau so gut könnte man verlangen, dass ein Ottomotor mit Wasser läuft. Das geht nicht. ;)

Vorraussetzungen. Da weiß ich gerade nicht was du im speziellen meinst. Ich muss aber gestehen, dass ich bei deinem Projekt nie so genau verstanden hatte was da woher kam und welche Teile von dir programmiert werden und welche schon von anderen programmiert wurden und von dir nur benutzt werden.