Unicode Compiler Option

[EWeiss]

Kleine Frage

Muss man in den Optionen vom Copiler etwas einstellen
oder irgendwelche Define im code eintragen damit Unicode auch auf verschiedenen Systemen(Sprachen) funktioniert ?

Hab da jemand in Korea sitzen wenn ich ihm meine DLL schicke funktioniert
Unicode nicht. Nur dann wenn er es selbst compiliert aud seinen System.

gruss Emil

[mkinzler]

Delphi wird erst mit der demnächst erscheinenden Delphi-Version ohne Fremdkomponenten unicodefähig

[EWeiss]

Zitat:

Zitat von mkinzler

Delphi wird erst mit der demnächst erscheinenden Delphi-Version ohne Fremdkomponenten unicodefähig

Ok dann hat sich das erledigt

Danke schön.

gruss Emil

[mkinzler]

Die letzte OpenSource-Version der TNT-Unicode-Komponentensammlung lässt sich noch finden
http://www.mh-nexus.de/tntunicodecontrols.htm

[EWeiss]

Zitat:

Zitat von mkinzler

Die letzte OpenSource-Version der TNT-Unicode-Komponentensammlung lässt sich noch finden
http://www.mh-nexus.de/tntunicodecontrols.htm

hab mir da was gebastelt von irgendeinen C++ code

Delphi-Quellcode:

function EncodeUTF8(const Source: WideString): string;
var
  Index, SourceLength, CChar: Cardinal;
begin
  { Convert unicode to UTF-8 }
  Result := '';
  Index := 0;
  SourceLength := Length(Source);
  while Index < SourceLength do
  begin
    Inc(Index);
    CChar := Cardinal(Source[Index]);
    if CChar <= $7F then
      Result := Result + Source[Index]
    else if CChar > $7FF then
    begin
      Result := Result + Char($E0 or (CChar shr 12));
      Result := Result + Char($80 or ((CChar shr 6) and $3F));
      Result := Result + Char($80 or (CChar and $3F));
    end
    else
    begin
      Result := Result + Char($C0 or (CChar shr 6));
      Result := Result + Char($80 or (CChar and $3F));
    end;
  end;
end;



function ToUnicodeString(s: pchar): WideString;
var
   pw1 : array[0..1024] of WideChar;
   nLen1, nLen2, nLen3 : integer;
begin
   nLen1 := Length(s);
   nLen2 := length(pw1);
   nLen3 := MultiByteToWideChar(CP_OEMCP, MB_PRECOMPOSED, s, nLen1, @pw1[0], nLen2);
   if nLen3 > 0 then
   begin
      pw1[nLen3] := chr(0);  // *** We should put chr(0) at the end of string
      Result := WideString(pw1);
   end else
      Result := '';
end;



function StrToUTF8(s: pchar): string;
var
   w_str : WideString;
begin
   w_str := ToUnicodeString(s);
   if w_str <> '' then
      result := EncodeUTF8(w_str)
   else
      result := '';
end;

Das funktioniert ohne problem
Aber nur wenn es auf dem jeweiligen System compiliert wird.
Was ist an der Komponente anders ?

gruss Emil

[mkinzler]

Es ist keine einzelne Komponente sondern eine Sammlung von vielen Standardkomponenten.

[EWeiss]

Zitat:

Zitat von mkinzler

Es ist keine einzelne Komponente sondern eine Sammlung von vielen Standardkomponenten.

wäre nicht schlecht nur für ein Freeware projekt Geld ausgeben
Soweit gehe ich dann doch nicht.

trotzdem Danke für den Hinweis.

Gruss Emil

[mkinzler]

Warum, diese Version ist doch frei

[EWeiss]

Zitat:

Zitat von mkinzler

Warum, diese Version ist doch frei

ich lese das was von preisen

Zitat:

"TMS Unicode Component Pack" with pricing at 30EU for a single developer license and 120EU for a

gruss Emil

[mkinzler]

Ja, aber bis zur Version 2.3.0 war die Sammlung OpenSource
http://www.yunqa.de/delphi/doku.php/...controls/index

[EWeiss]

Zitat:

Zitat von mkinzler

Ja, aber bis zur Version 2.3.0 war die Sammlung OpenSource
http://www.yunqa.de/delphi/doku.php/...controls/index

ahh danke das werd ich mir mal anschauen.

gruss Emil

[EWeiss]

Also wir haben das mal getestet
Compiliert in D2006 für Unicode funktioniert nicht auf einen Koreanischen System
Compiliert mit D7 Enterprise funktioniert hier und auch auf einen koreanischen System

also irgendwas ist da faul..
Weiß da jemand etwas genaueres drüber ?

packt der Compiler von D2006 das nicht ?

gruss Emil

[Bernhard Geyer]

Zitat:

Zitat von EWeiss

hab mir da was gebastelt von irgendeinen C++ code

Wieso nimmst du nicht die schon vorhandenen Delphi-Funktionen bezüglich UTF8-Codierung/Decodierung?

Zitat:

Zitat von EWeiss

Compiliert in D2006 für Unicode funktioniert nicht auf einen Koreanischen System
Compiliert mit D7 Enterprise funktioniert hier und auch auf einen koreanischen System

also irgendwas ist da faul..
Weiß da jemand etwas genaueres drüber ?

Was funktioniert denn nicht bzw. in welchen Fällen funktioniert es nicht? Nur bei DLL oder wenn alles in einer Exe ist? Wird auch die Exe mit D2006 kompiliert und du verwendest nicht korrekt eine C-Kompatible DLL-Schnittstelle.

[EWeiss]

Zitat:

Wieso nimmst du nicht die schon vorhandenen Delphi-Funktionen bezüglich UTF8-Codierung/Decodierung?

Weil sie nicht funktionieren warum auch immer das ist ja mein Rätzel
mit dem ich mich rumschlage.

Zitat:

Was funktioniert denn nicht bzw. in welchen Fällen funktioniert es nicht? Nur bei DLL oder wenn alles in einer Exe ist? Wird auch die Exe mit D2006 kompiliert und du verwendest nicht korrekt eine C-Kompatible DLL-Schnittstelle.

Kann ich nicht wiedergeben ..
Nur das eine das die Schriftzeichen wenn in D7 compiliert 100% in Ordnung sind
und mit dem Compiler von D2006 nicht.

Beide haben den gleichen Source von der visualisierung aber unterschiedliche Exe-Dateien.
Also an der EXE kann es nicht liegen.

Kompiliert er auf seinen Koreanischen System mit D7 dann werden bei mir die Umlaute korrekt angezeigt
Mache ich es hier mit D2006 fehlen bei ihm einige zeichen.
Mit D7 ist alles in Ordnung das wundert mich ja.

EDIT:
Habe es mit meiner version siehe oben und mit dem "TMS Unicode Component Pack"
getestet beides bleibt gleich und funktioniert genau so gut kann mir diese also sparen
Es ist ein reines compiler problem.

gruss Emil

[Bernhard Geyer]

Wie werden denn die Text im Sourcecode angegeben?
Und wieso arbeitest du mit PChars als übergabe wenn du eigentlich Unicode-Zeichen hast?

[EWeiss]

Zitat:

Zitat von Bernhard Geyer

Wie werden denn die Text im Sourcecode angegeben?
Und wieso arbeitest du mit PChars als übergabe wenn du eigentlich Unicode-Zeichen hast?

Ich arbeite mit der TextSuite die setzt PChar vorraus..
Die Texte werden aus der Anwendung als String übergeben bzw.. auch wieder als PChar oder WideString.
Ist abhängig von dem was die Leute über ihre Anwendung an BassVis schicken und dann innerhalb
der vis_BassVis verarbeitet wird.

VB kennt kein WideString usw..
Ich kann also keinen reinen WideString innerhalb vis_BassVis verwenden
sondern das was ankommt und das kann viel sein.
Deshalb meine Funktion die dafür sorgt das der ankommende Text ins Unicode Format konvertiert wird.

Aber wie gesagt alles spekulativ da es in D2006 mit dem Compiler einfach nicht
richtig gebunden wird warum auch immer.
Anders sehe ich das nicht denn wie schon gesagt in D7 gehts.

Wüßte auch nicht warum der in Korea mir da was erzählen sollte was nicht stimmt. (Überprüfen kann ich allerdings nicht!)

gruss Emil

[mkinzler]

Versuchs es mal mit PWideChar

[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.

Denke kann das problem so nicht lösen
Werd die DLL dann mit D7 kompilieren wenn ich sie fertig ist.

gruss Emil

[mkinzler]

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

[OldGrumpy]

Zitat:

Zitat von EWeiss

Ich arbeite mit der TextSuite die setzt PChar vorraus..

Schon da kommt dann die auf dem jeweiligen Rechner eingestellte Codepage zum Tragen. Hast Du in der Exe für den Koreaner die Ländereinstellungen für die Exe entsprechend justiert? Ich empfehle einen umfassenden Exkurs in das Thema "i18n richtig gemacht" :)

Zitat:

Zitat von EWeiss

Die Texte werden aus der Anwendung als String übergeben bzw.. auch wieder als PChar oder WideString.

Auch da ist die Wandlung immer vom jeweiligen System abhängig. Wenn Windows die Exe für koreanisch hält (weil der koreanische Compiler ebenso wie Deiner standardmäßig die Systemeinstellungen dafür hernimmt), funktioniert die Wandlung von UCS-2 nach Ansi und umgekehrt, ansonsten nicht.

Zitat:

Zitat von EWeiss

Ist abhängig von dem was die Leute über ihre Anwendung an BassVis schicken und dann innerhalb der vis_BassVis verarbeitet wird.

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

Zitat:

Zitat von EWeiss

VB kennt kein WideString usw..

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.

Zitat:

Zitat von EWeiss

Ich kann also keinen reinen WideString innerhalb vis_BassVis verwenden sondern das was ankommt und das kann viel sein. Deshalb meine Funktion die dafür sorgt das der ankommende Text ins Unicode Format konvertiert wird.

Ja, und dementsprechend funktioniert es manchmal, manchmal nicht. Reite dieses tote Pferd bitte nicht weiter sondern machs lieber richtig :)

Zitat:

Zitat von EWeiss

Aber wie gesagt alles spekulativ da es in D2006 mit dem Compiler einfach nicht richtig gebunden wird warum auch immer. Anders sehe ich das nicht denn wie schon gesagt in D7 gehts.

Falscher Ansatz. Es ist wohl eher so, dass D2006 es richtig macht, D7 aber nicht, und eher zufällig der Anschein erweckt wird, D7 machte es richtig. Das kann an der nächsten Ecke schon wieder ganz anders aussehen und spätestens dann wirst Du wieder auf die Nase fallen mit dem falschen Ansatz.

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

Zitat:

Zitat von EWeiss

Wüßte auch nicht warum der in Korea mir da was erzählen sollte was nicht stimmt. (Überprüfen kann ich allerdings nicht!)

Tut er ja gar nicht :)

[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.

[EWeiss]

Zitat:

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.

Na ja was da zu verstehen ist ..
Einmal was ich hier erarbeitet habe das ist ne menge schau dir doch die Threads an.
TextSuite natürlich nicht habe ich auch nie als meine Arbeit ausgegeben.
Genau so wenig wie die OpenGL Header.

Leute die einen beitrag geleistet haben stehen im About Dialog.
Und abschließend ja bin kein Profi so wie du .. muß man also nicht abwerten.

Zu allerletzt mache ich das für die öffenlichkeit das alle was davon haben.
Meistens sind es LEute wie ich die so etwas auf die Beine stellen.
Informatiker geben sich damit nicht ab.

Das war dann genug OffTopic.

Nehme es dir aber nicht übel ..

gruss Emil

[Lossy eX]

Ich glaube da gab es gerade ein Missverständniss. Ich wollte dich damit keineswegs in irgendeiner Art angreifen oder das Thema OffTopic werden lassen. Ich muss aber gestehen, dass ich mich, in dem von dir zitierten Teil, nicht wirklich gut ausgedrückt habe. :roll:

Ich habe lediglich versucht heraus zu finden
- woher die Texte kommen?
- welchen Weg sie durch die Anwendung/Plugins etc. nehmen?
- und auf welche Programmteile du Einfluss nehmen kannst?

Also insgesammt wie die Verarbeitung der Texte von statten geht? Denn ich für meinen Teil weiß nicht wie die Visualisierung und die VB Codes dort genau zusammen gehören und was die VB Codes zu den Texten beitragen. Und ich weiß auch nicht welche Rolle der Player dabei spielt. Und die Texte werden ja vermutlich über mehrere Programmteile gereicht. Und die müssen dann alle damit klar kommen.

Und das Ganze interessiert mich unter folgendem Hintergrund. Solltest du "nur" ein Visualisierungsplugin für einen bestehenden Player schreiben und wenn dieser dir nur ansi texte reicht, dann sehe ich so keine Möglichkeit da wirklich volle Unicode unterstützung zu ermöglichen. Denn woher solltest du die Informationen dann schon nehmen. Möchtest du aber auch den Player dazu schreiben, dann sieht das evtl. schon wieder ganz anders aus.

[EWeiss]

Zitat:

- woher die Texte kommen?
- welchen Weg sie durch die Anwendung/Plugins etc. nehmen?
- und auf welche Programmteile du Einfluss nehmen kannst?

Eine vom Developer geschriebene Anwendung VB, Net, Delphi, C++ oder was auch immer
verwendet den von mir entwickelten Wrapper welcher verschiedene Plugin Kinder verwaltet
Winamp, Sonique, WMP und BassBox.

Die Anwendung schickt die Texte und andere dinge an den Wrapper für das jeweilige Visualisations Plugin das er verwendet.
Der Wrapper schickt und holt Daten vom Plugin und gibt sie zurück an die Anwendung.
Das Plugin arbeitet nur mit dem Wrapper zusammen stört sich nicht an der Anwendung.
Alle Callbacks usw.. laufen also über den.

Die ganze sache geht also über drei verschiedene Kanäle
während es bei Winamp nur einer ist.

Ich kann auf alle Programmteile einfluss nehmen..
Habe für fast alle Sprachen die unterstützt werden ein Sample geschrieben
So das der User mit der Library vernünftig arbeiten kann.
VB, C#, Delphi, VB_Net für mehr hats nicht gereicht.

EDIT:
Das Plugin ist eigentlich für Winamp konzipiert.
Und der sollte mit Unicode eigentlich klar kommen.
Da mein Wrapper aber das VisInterface unterstützt habe ich nun das problem mit unicode
wenn eine andere Anwendung dieses verwenden will.

gruss Emil

[Lossy eX]

Wenn ich das richtig verstanden habe, dann hast du ein Pluginsystem geschrieben welches Plugins von verschiedenen Typen (winamp, sonique etc) ansteuern kann?

Benutzt du für deinen Wrapper eine eigene Schnittstelle oder eine die schon existiert? Also um deinen Wrapper im Winamp benutzen zu können. Dann wäre der Wrapper auch eine Winamp Visualisierung und könntest dann Visualisierungen aus anderen Programmen benutzen. Wenn du eine bestehende Schnittstelle benutzt wie sieht die denn aus? Bzw wie werden da die Daten übergeben?

Wobei ich gerade mal mit dem MediaMonkey und der Windows Zeichentabelle mal ein paar kyrillische Buchstaben zusammen geklickt habe und diese als Dateiname und als Titel eingefügt hatte. Und dort kam im Milkdrop der passende Text an (sofern das passende Fonts ausgewählt wurde). Milkdrop ist eigentlich ein Winamp plugin und MediaMonkey ein Delphi Program was Winamp Plugins benutzen kann. Ich weiß aber nicht wie das da intern geregelt wird. Und unter Vorbehalt dass ich dich richtig verstanden habe.

[EWeiss]

Zitat:

Benutzt du für deinen Wrapper eine eigene Schnittstelle oder eine die schon existiert?

Eine eigene API

Zitat:

Also um deinen Wrapper im Winamp benutzen zu können.

Nein nur um di Plugins von Winamp nutzen zu können (vis_BassVis) als Beispiel

Zitat:

Dann wäre der Wrapper auch eine Winamp Visualisierung und könntest dann Visualisierungen aus anderen Programmen benutzen.

Keine Visualisierung eine schnittstelle zwischen Anwendung und Plugin Kind

Zitat:

Bzw wie werden da die Daten übergeben?

So..

Delphi-Quellcode:

{' UNIT BassVis.pas
'--------------------------- BassVis API Module -----------------------------
' BassVis ADD-ON for Bass Audio Library
' Copyright © 2006-2008 BrewIdeas@Emil Weiss, All Rights Reserved
'
' Author(s) of this Unit: Emil Weiss
'
' Code was written in and formatted for 10pt Courier New
'----------------------------------------------------------------------------}

unit BassVis;

interface

uses
  Windows;

type
  HVIS = DWORD;
  QWORD = Int64;

const

  dllfile = 'bass_vis.dll';                  //filename of the DLL
  
  // BASS_SONIQUEVIS_CreateVis flags
  BASS_VIS_NOINIT = 1;

  // BASS_SONIQUEVIS_SetConfig flags
  BASS_SONIQUEVIS_CONFIG_FFTAMP         = 1;
  BASS_SONIQUEVIS_CONFIG_FFT_SKIPCOUNT  = 2; // Skip count range is from 0 to 3 (because of limited FFT request size)
  BASS_SONIQUEVIS_CONFIG_WAVE_SKIPCOUNT = 3; // Skip count range is from 0 to (...) try it out, whenever Bass crashes or does not return enough sample data
  BASS_SONIQUEVIS_CONFIG_SLOWFADE       = 4; // Dim light colors to less than half, then slowly fade them out

  // BASS_WINAMP_SetConfig flags
  BASS_WINAMPVIS_CONFIG_FFTAMP = 1;

  // BASS_WMPVIS_SetConfig flags
  BASS_WMPVIS_CONFIG_FFTAMP = 1;

  // BASS_VIS_FindPlugin flags
  BASS_VIS_FIND_RECURSIVE = 4;

  //Plugin arten
  BASSVISKIND_NONE    = 0; // keins aktiv
  BASSVISKIND_WINAMP  = 1; // Winamp
  BASSVISKIND_SONIQUE = 2; // Sonique
  BASSVISKIND_WMP     = 3; // WMP
  BASSVISKIND_BASSBOX = 4; // BassBox
  
type
  TBASSVIS_KIND_T = integer;

  PBASSVIS_PARAM = ^TBASSVIS_PARAM;
  TBASSVIS_PARAM = record
    VisHandle          : HVIS;            // VisHandle
    VisWinHandle       : HWND;            // Vis Window Handle         W2
    VisGenWinHandle    : HWND;            // General Vis Window Handle W5
    Kind               : TBASSVIS_KIND_T; // Aktive Plugin Art
  end;

  //Definition der Records für die variablen Parameter bei Create bzw. Execute
  //WMP: Handle des Fensters braucht nicht definiert werden, da es bereits beim init mitgegeben wird
  PBASSVIS_EXEC = ^TBASSVIS_EXEC;
  TBASSVIS_EXEC = record
    AMP_SON_BB_Pluginfile : PChar; // Dateiname des Plugins
                                    // für Sonique, Winamp, BassBox
    AMP_UseOwnW1          : DWORD;    // Flag für Winamp (ownHDC)
    AMP_UseOwnW2          : DWORD;    // Flag für Winamp (ownHDCW2)
    AMP_Moduleindex       : DWORD;    // Modul-index für Winamp
    SON_PaintHandle       : HDC;      // Painthandle für Sonique
    SON_ConfigFile        : PChar;    // Dateiname der Konfiguration für Sonique
    SON_Flags             : DWORD;    // Flags für Sonique
    WMP_PluginIndex       : integer;  // Pluginindex für WMP;
    WMP_PresetIndex       : integer;  // Presetindex für WMP;
    WMP_SrcVisHandle      : HWND;     // ContainerVisHandle für WMP;
    BB_ParentHandle       : HWND;     // Parent Windowhandle
    BB_Flags              : DWORD;    // Flags für BassBox selbe wie Sonique
    BB_ShowFPS            : BOOL;     // Frames pro Sekunde anzeigen
    BB_ShowPrgBar         : BOOL;     // Progressbar anzeigen
    Width, Height         : integer;  // Fensterhöhe und Breite
    Left, Top             : integer;  // Left und Top;
  end;

  PBASSVIS_INFO = ^TBASSVIS_INFO;
  TBASSVIS_INFO = record
    SongTitle   : PChar;   // Titel mit vorstehener TitelNr ('1. ')
    Songfile    : PChar;   // SongTitel incl. Pfad
    pos         : DWORD;   // 1000 * Aktuelle Position im Stream
    len         : DWORD;   // Stream länge
    PlaylistPos : DWORD;   // Playlist Position
    Playlistlen : DWORD;   // Playlist einträge
    SampleRate  : integer; // SämpleRate
    BitRate     : integer; // BitRate
    Duration    : DWORD;   // abgelaufen Zeit
    Channels    : integer; // Kanäle default 2 (stereo)

  end;

  TPlayState    = (psError = 99, psStop = 0, psPlay = 1,
                   psIsPlaying = 2, psPause= 3,
                   psPrevTitle = 4, psNextTitle = 5,
                   psSetPlaylistTitle = 6, psGetPlaylistTitlePos = 7,
                   psSetPlaylistPos = 8, psGetSelectedTitlePos = 9);


TBASSVIS_STATECALLBACK = procedure(NewState:TPlayState); stdcall;

function BASSVIS_Init(Kind: TBASSVIS_KIND_T;
    AppHandle: HWND;
    WinHandle: HWND
): BOOL; stdcall; external dllfile;


function BASSVIS_FindPlugins(Kind: TBASSVIS_KIND_T;
    PluginPath: PChar;
    Searchflags: DWORD;
    delimiter : char = ','
): PChar; stdcall; external dllfile;


function BASSVIS_GetPluginHandle(Kind: TBASSVIS_KIND_T;
    Pluginfile: PChar
): DWORD; stdcall; external dllfile;


procedure BASSVIS_ExecutePlugin(Param: PBASSVIS_EXEC;
    var Base: TBASSVIS_PARAM
); stdcall; external dllfile;


function BASSVIS_RenderChannel(Param: PBASSVIS_PARAM;
    channel: DWORD
): BOOL; stdcall; external dllfile;


function BASSVIS_StartRecord(Param: PBASSVIS_PARAM;
    SampleRate: integer = 44100;
    Channels: integer = 2
): BOOL; stdcall; external dllfile;


function BASSVIS_Config(Param: PBASSVIS_PARAM;
    Entry: integer = 0
): BOOL; stdcall; external dllfile;


function BASSVIS_SetInfo(Param: PBASSVIS_PARAM;
    Infos: PBASSVIS_INFO
): BOOL; stdcall; external dllfile;


function BASSVIS_Resize(Param: PBASSVIS_PARAM;
    Left,Top,Width,
    Height: DWORD
): BOOL; stdcall; external dllfile;


function BASSVIS_SetFullscreen(Param: PBASSVIS_PARAM;
    SourceHandle, DestHandle: HWND;
    SourceLeft, SourceTop,
    SourceWidth, SourceHeight: DWORD;
    FullScreenFlag: Boolean;
    FullScreeWidth, FullScreenHeight: DWORD
): BOOL; stdcall; external dllfile;


function BASSVIS_GetModulePresetCount(Param: PBASSVIS_PARAM;
    PluginName: PChar
): integer; stdcall; external dllfile;


function BASSVIS_GetModulePresetName(Param: PBASSVIS_PARAM;
    index: integer;
    PluginName: PChar = nil
): PChar; stdcall; external dllfile;


function BASSVIS_GetModulePresetNameList(param: PBASSVIS_PARAM;
   Pluginname:Pchar = NIL
):Pchar;stdcall; external dllfile;


function BASSVIS_GetOption(Param: PBASSVIS_PARAM;
    option: integer
): integer; stdcall; external dllfile;


function BASSVIS_SetOption(Param: PBASSVIS_PARAM;
    option: integer;
    Value: integer
): BOOL; stdcall; external dllfile;


function BASSVIS_SetPlayState(Param: PBASSVIS_PARAM;
    State: TPlayState;
    Value: integer = -1;
    Title: PChar = nil
): integer; stdcall; external dllfile;


procedure BASSVIS_SetVisPort(Param: PBASSVIS_PARAM;
    WindowHandle: HWND;
    ContainerHandle: HWND;
    x, y, Width, Height: integer
); stdcall;external dllfile;


function BASSVIS_GetPluginName(Param: PBASSVIS_PARAM): PChar; stdcall; external dllfile;
function BASSVIS_IsFree(Param: PBASSVIS_PARAM): BOOL; stdcall; external dllfile;
function BASSVIS_Free(Param: PBASSVIS_PARAM): BOOL; stdcall; external dllfile;
function BASSVIS_GetVersion: pchar; stdcall; external dllfile;
procedure BASSVIS_Quit(Param: PBASSVIS_PARAM);stdcall; external dllfile;

//Spezial für Winamp
procedure BASSVIS_WINAMP_SetStateCallback(callback:TBASSVIS_STATECALLBACK);stdcall;external dllfile;
procedure BASSVIS_WINAMP_RemoveCallback;stdcall;external dllfile;

//Spezial für Sonique
function BASSVIS_SONIQUEVIS_Clicked(handle: HVIS; x, y: DWORD): boolean; stdcall;external dllfile;
function BASSVIS_SONIQUEVIS_RenderToDC(Kind: TBASSVIS_KIND_T; handle: HVIS; channel: DWORD; canvas: HDC): boolean; stdcall; external dllfile;
function BASSVIS_SONIQUEVIS_RenderToDC2(Kind: TBASSVIS_KIND_T; handle: HVIS; Data, fft: Pointer; canvas: DWORD; flags, pos: DWORD): boolean; stdcall; external dllfile;

//Spezial für WMP
function BASSVIS_SetModulePreset(Param: PBASSVIS_PARAM;index: integer): BOOL; stdcall; external dllfile;

implementation

end.

Also die API ist Delphi und mein Hauptsample ist auch in Delphi

gruss Emil

[Muetze1]

Moin!

Ich sehe da überall PChar und somit 1-Byte Zeichensätze und kein Widestring. Somit wird da intern von Delphi konvertiert und es kommt immer was anderes raus, wenn Widestrings übergeben werden.

MfG
Muetze1

[EWeiss]

Zitat:

Zitat von Muetze1

Moin!

Ich sehe da überall PChar und somit 1-Byte Zeichensätze und kein Widestring. Somit wird da intern von Delphi konvertiert und es kommt immer was anderes raus, wenn Widestrings übergeben werden.

MfG
Muetze1

Ja korrekt wenn ich es für Unicode ändern muss wäre das kein Problem.
Damit wäre es aber nicht erledigt denn wie lossy sagt wäre das nächste FindNext und FindFirst in der DLL

überlege.....
Wenn die Schnittstelle und BassVis nicht korrekt auf Unicode umgestellt werden gehts auch mit anderen
Plugins nicht welche UC unterstützen.

gruss Emil

[Muetze1]

Moin!

Zitat:

Zitat von EWeiss

Damit wäre es aber nicht erledigt denn wie lossy sagt wäre das nächste FindNext und FindFirst in der DLL

Es beschränkt sich nicht darauf sondern auf alle WinAPI Funktionen - entweder direkt oder indirekt (RTL/VCL) aufgerufen.

MfG
Muetze1

[Lossy eX]

Also ich denke auch das du das ändern solltest. Dann wäre es in jedem Fall ein solider Stand. In der TextSuite habe ich es ähnlich wie die Windows API gehalten. Also von den Methoden mit Text gibt es 2 Varianten. Die Ansi Methoden haben ein A am Ende und die für WideString ein W. Und intern arbeite ich überwiegend nur mit WideStrings. Die Ansi Varianten konvertieren den Text vorher in einen WideString. Außnahme sind Dateinamen, da ich nicht weiß wie das Gegenstück in Linux heißt.

Windows API (FindFirst/FindNext): In der Windows API haben alle Methoden mit Strings 2 Varianten. Allerdings dürfte für dich wahrscheinlich nur ein paar wirklich von interesse sein. FindFirstW/FindNextW und CreateFileW werfe ich mal so in den Raum. Und eventuell eine GUI. Denn so extrem viele wirklich abhängigen Sachen wirst du vermutlich gar nicht nutzen. Für solche Dinge wie "Private" Einstellungen in der Registry gibts zwar auch Unicode Varianten aber die werden nicht nötig sein.

[EWeiss]

Danke an alle für ihre Teilnahme
Werde dann erst mal meine API nach dem Vorschlag von @mkinzler nach PWideChar umstellen.
Schaden kann das nicht.

gruss Emil