Memorystream vs TMemoryStream

[EWeiss]

Der Müll kommt bei ihm an.
Deshalb kracht es.

Kann mir da jemand helfen ?
Bei bedarf häng ich das Projekt mal an.

gruss

[Lemmy]

warum eigentlich nicht "einfach" MemoryMappedFiles verwenden?
https://msdn.microsoft.com/de-de/lib...vs.110%29.aspx

sind doch genau dafür da.. Gut bisher habe ich da auch "nur" Daten zwischen Delphi-Prozessen ausgetauscht, aber damit sollte das doch problemlos auch nach .net gehen solange die komplette Bilddatei dort abgelegt wird...

[EWeiss]

Zitat von Lemmy:

warum eigentlich nicht "einfach" MemoryMappedFiles verwenden?
https://msdn.microsoft.com/de-de/lib...vs.110%29.aspx

sind doch genau dafür da.. Gut bisher habe ich da auch "nur" Daten zwischen Delphi-Prozessen ausgetauscht, aber damit sollte das doch problemlos auch nach .net gehen solange die komplette Bilddatei dort abgelegt wird...

Danke.
Es geht nicht alleine nur um die Bitmap die ich an CoverArtData.Data übergeben muss
sondern um die struct TCoverArtData.

So wie im Bild ersichtlich kommt auf der Delphi Seite nur Müll an.
Bin wohl damit überfordert

gruss

[Lemmy]

Zitat von EWeiss:

So wie im Bild ersichtlich kommt auf der Delphi Seite nur Müll an.
Bin wohl damit überfordert

ist doch logisch.. das Objektmodell von Delphi entspricht halt nicht dem von .NET. Jemand der sich damit auskennt kann dir das erklären wo die Unterschiede in der Speicherverwaltung von Delphi und .net liegen (wo sind virtuelle Methoden definiert, wo die Eigenschaften....) wenn das nicht zusammen passt, dann kann bei der Interpretation auch nur Müll raus kommen.

Lösung:
Das Objekt/Record in eine XML-Datei speichern, das Bitmap dazu (mime), ggf. zippen und die komplette XML dann ins MMF. Das kannst Du dann mit jeder bel. Programmiersprache auswerten, die MMF unterstützt...

Nachtrag: Die Größe des MMF kannst Du dann per Windows-Message "herum reichen" auf die dann das andere Programm reagieren kann - das weiß dann ab wann die Infos komplett bereit stehen und auch wie groß die MMF ist in der die Daten stehen...


Grüße

[EWeiss]

Zitat von Lemmy:

Zitat von EWeiss:

So wie im Bild ersichtlich kommt auf der Delphi Seite nur Müll an.
Bin wohl damit überfordert

ist doch logisch.. das Objektmodell von Delphi entspricht halt nicht dem von .NET. Jemand der sich damit auskennt kann dir das erklären wo die Unterschiede in der Speicherverwaltung von Delphi und .net liegen (wo sind virtuelle Methoden definiert, wo die Eigenschaften....) wenn das nicht zusammen passt, dann kann bei der Interpretation auch nur Müll raus kommen.

Lösung:
Das Objekt/Record in eine XML-Datei speichern, das Bitmap dazu (mime), ggf. zippen und die komplette XML dann ins MMF. Das kannst Du dann mit jeder bel. Programmiersprache auswerten, die MMF unterstützt...

Nachtrag: Die Größe des MMF kannst Du dann per Windows-Message "herum reichen" auf die dann das andere Programm reagieren kann - das weiß dann ab wann die Infos komplett bereit stehen und auch wie groß die MMF ist in der die Daten stehen...


Grüße

Das macht keinen Sinn sorry.
Ich habe selbst eine DLL in Delphi geschrieben und einen Wrapper dazu.
Bei mir ist es nur so das ich weis welche Dateien bzw. DataTypen in Delphi deklariert werden müssen
damit eine Zusammenarbeit beider Sprachen ohne große Probleme funktioniert.

Aber wie gesagt darauf habe ich kleinen Einfluss was oder wie er seine Daten verwaltet/übergibt.
Zudem macht es absolut keinen sinn irgendetwas in ZIP Dateien zu packen denn ich lese den TAG einer X-Beliebigen MP3 Datei aus
und die Bilddatei ist im Tag enthalten.
Soll ich das dann zippen ?

gruss

[EWeiss]

Zitat:

Ich würde ernsthaft vorschlagen, die Herangehensweise zu überdenken. Es wäre besser, die ganze Funktionalität in einer komplett nativen Delphi-DLL zu verpacken, nur die Methoden zu exposen, und ausschliesslich primitive Datentypen zwischendrin auszutauschen. Oder, Du nimmst sowas wie Hydra, das Dir dann wirklich erlaubt komplette Interfaces zwischen .NET und Delphi hin- und her zu schieben, und das ganze Plugin-Framework kümmert sich für Dich dann um das ganze richtige Konvertieren etc.

Würde ich gerne machen wenn es denn meine DLL wäre.
NA ja die Strings hab ich nach IntPtr gecastet das ist kein Problem.
Das ich mit Strings keine Probleme habe kannst du sehen siehe Anhang.

Delphi-Quellcode:

type
    TCoverArtData = packed record
        Name: PWideChar;
        Data: Pointer;
        DataSize: Int64;
        Description: PWideChar;
        CoverType: DWord;
        MIMEType: PWideChar;
        PictureFormat: TTagPictureFormat;
        Width: DWord;
        Height: DWord;
        ColorDepth: DWord;
        NoOfColors: DWord;
        ID3v2TextEncoding: Integer;
        Index: Integer;
    end;

Code:

  [Serializable, StructLayout(LayoutKind.Sequential, Pack = 1)]
  public sealed class TCoverArtData
  {
    private IntPtr NameSPtr;
    public IntPtr Data;
    public long DataSize;
    private IntPtr DescriptionSPtr;
    public int CoverType;
    private IntPtr MIMETypeSPtr;
    public TTagPictureFormat PictureFormat;
    public int Width;
    public int Height;
    public int ColorDepth;
    public int NoOfColors;
    public int ID3v2TextEncoding;
    public int Index;

    public string Name
    {
      get 
      {
        if (NameSPtr == IntPtr.Zero)
          return null;
        else
          return Marshal.PtrToStringAuto(NameSPtr);        
      }

      set 
      { 
        NameSPtr = Marshal.StringToHGlobalAuto(value); 
      }
    }

    public string Description
    {
      get 
      {
        if (DescriptionSPtr == IntPtr.Zero)
          return null;
        else
          return Marshal.PtrToStringAuto(DescriptionSPtr);
      }

      set 
      { 
        DescriptionSPtr = Marshal.StringToHGlobalAuto(value); 
      }

    }

    public string MIMEType
    {
      get 
      {
        if (MIMETypeSPtr == IntPtr.Zero)
          return null;
        else
          return Marshal.PtrToStringAuto(MIMETypeSPtr);
      }
      set 
      { 
        MIMETypeSPtr = Marshal.StringToHGlobalAuto(value); 
      }
    }

  }

gruss

[Phoenix]

Zitat von EWeiss:

Das macht keinen Sinn sorry.

Ich habe selbst eine DLL in Delphi geschrieben und einen Wrapper dazu.
Bei mir ist es nur das das ich weis welche Dateien bzw. DataTypen in Delphi deklariert werden müssen
damit eine Zusammenarbeit beider Sprachen ohne große Probleme zurechtkommen.

Aber wie gesagt darauf habe ich kleinen Einfluss was oder wie er seine Daten verwaltet/übergibt.

Das macht keinen Sinn. Sorry.

Du sagst uns nicht, was Du genau machen willst bzw. musst.

Du sagst uns nicht, welcher Teil genau in Delphi ist und welcher genau in C#. Aktuell sieht es (zumindest für mich) NICHT danach aus, das Du eine DLL ansprechen willst. Es sieht für mich danach aus, als ob Du ein Stück Delphi-Code 1:1 nach C# portieren = duplizieren willst. Inklusive UI. Das hat mit Bibliotheken/DLL (einmal geschriebener Code, der eben nicht für andere Plattformen kopiert werden muss) ehrlich gesagt genau gar nichts zu tun.

Du sagst uns nicht, was der Delphi-Code machen soll, wie das Interface Deiner Delphi-DLL aussieht die Du vielleicht(? - siehe vorherigen Absatz) aus .NET ansprechen willst.

Du sagst uns auch nicht, wer der andere ist, der seine Daten (welche?) verwaltet und übergibt. Auch das ist für mich gerade Sinnbefreit, denn wenn Du eine DLL bereit stellst, definierst Du damit da genau die Schnittstelle, über die jemand anderes Daten an Dich übergibt. Eigentlich hast Du damit die 100%ige Kontrolle darüber, wie jemand seine Daten an Dich zu übergeben hat.

Ich kenne Deine Systeme und die Systemgrenzen nicht. Ich sehe doppelten udn nicht mehrfach verwendeten Code, und ich sehe das Du da zwei Plattformen hast, deren interne Datenstrukturen die Du direkt übergeben willst (sinnlos) grundlegend inkompatibel sind.

Sorry, aber um da wirklich Zielführend zu helfen brauch ich echt viel mehr Informationen.

[Phoenix]

Zitat von EWeiss:

Ich habe selbst eine DLL in Delphi geschrieben und einen Wrapper dazu.

Zitat von EWeiss:

Würde ich gerne machen wenn es denn meine DLL wäre.

Ja was denn nun? Ist es Deine Dll, oder nicht?

[EWeiss]

Zitat von Phoenix:

Zitat von EWeiss:

Ich habe selbst eine DLL in Delphi geschrieben und einen Wrapper dazu.

Zitat von EWeiss:

Würde ich gerne machen wenn es denn meine DLL wäre.

Ja was denn nun? Ist es Deine Dll, oder nicht?

Damit habe ich gesagt das ich selbst schon für meine eigene DLL einen Wrapper geschrieben habe und dort alles funktioniert.
Nein es ist nicht meine DLL.

Habe oben mal das Beispiel angehängt.
Ohne Quelltext.
Wenn nötig poste ich ihn gern.

gruss

[Phoenix]

Uh. Es ist nahezu ein Ding der Unmöglichkeit, ein Struct in .NET so zu layouten, das die Datenstruktur so aussieht, wie sie bei Delphi aussieht.

Insbesondere, wenn Du hier Strings (die sind komplett inkompatibel, weil die in .NET immer immutable Objekte sind) und eben größere Binärdaten hin- und herschieben willst.

Nur ein Beispiel: In .NET ist ein String ein Objekt, und die Daten werden geshared. Will heissen, wenn Du 15 Strings hast, und 13 davon identischen Inhalt haben, hast Du im Endeffekt 15 Objekte (also eine Komplexe Datenstruktur), und 13 davon haben intern irgendwo einen Pointer auf den selben Datenbereich mit dem Inhalt des Strings und 2 zeigen woanders hin. Wenn Du den Inhalt eines der 13 Strings jetzt änderst, dann wird geschaut, ob es den Inhalt schonmal gibt, wenn ja, wird einfach nur der Pointer verbogen, wenn nein, wird der Inhalt halt irgendwo neu angelegt und dann der Zeiger darauf hin verbogen. Das .NET Managed ist, bekommst Du ohne ganz hartes natives Debugging auch nicht raus, an welcher Speicherstelle der String jetzt eigentlich wirklich liegt.

Das, was Du machen willst, involviert sehr viel unsafe Code.

Ich würde ernsthaft vorschlagen, die Herangehensweise zu überdenken. Es wäre besser, die ganze Funktionalität in einer komplett nativen Delphi-DLL zu verpacken, nur die Methoden zu exposen, und ausschliesslich primitive Datentypen zwischendrin auszutauschen. Oder, Du nimmst sowas wie Hydra, das Dir dann wirklich erlaubt komplette Interfaces zwischen .NET und Delphi hin- und her zu schieben, und das ganze Plugin-Framework kümmert sich für Dich dann um das ganze richtige Konvertieren etc.