![]() |
Re: Unicode Compiler Option
Zitat:
Schick dir gern den Quelltext zum testen zu. Seltsam ist das schon das ganze. gruss Emil |
Re: Unicode Compiler Option
Zitat:
Zitat:
Nur die EXE laufen nicht ohne Bass.dll und BassVis Zitat:
Es gibt eine auswahlmöglichkeit. Zusätzlich noch eine andere den BitmapFont zu verwenden. gruss Emil |
Re: Unicode Compiler Option
Zitat:
Da ich noch nicht einen vollständigen Test mit D2007 erledigt habe vermute ich eher ein internen Handlingfehler mit PChar/PWideChar/String/AnsiString. |
Re: Unicode Compiler Option
Zitat:
Mit internas von Delphi, mit der CodePage funktion der TextSuite selbst und mit der von mir zusammengeschusterten version. hmmm......... gruss Emil |
Re: Unicode Compiler Option
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? |
Re: Unicode Compiler Option
Zitat:
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 |
Re: Unicode Compiler Option
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:
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. |
Re: Unicode Compiler Option
Zitat:
Dann könnte es an einer verhunzten ("Optimierten") Installation liegen Zitat:
|
Re: Unicode Compiler Option
Zitat:
EDIT: @Lossy Zitat:
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 |
Re: Unicode Compiler Option
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:16 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz