IStream-Interface als Parameter in C# (eigtl. Delphi Interface)

[HuDeanY]

Servas

Nachdem ich nun schon ne ganze Weile hier im Forum mitschmöckere hab ich denn dann auch mal ein für mich nicht lösbares Problem:

Ich arbeite an einer Portierung einer Win-32 Anwendung von Delphi (und C++) in C#, was nebenbei auch noch mein IHK-Abschlussprojekt ist.

Die Problematik ist nun folgende:

Ich muss ein COM-Object aus C# heraus erzeugen und benutze dazu eine vorgegebene Erzeuger-Klasse, die in C++ geschrieben wurde. Bisher geschah das aus einem Delphi-Programm heraus. Diese Erzeuger-Klasse will zum Erzeugen des gewünschten COM-Objektes einige Parameter haben. Unter diesen (5) Parametern ist auch ein IStream. Und jetzt kommt der springende Punkt ... Dieses Interface "IStream" gibt es in C# nicht.

Ich programmiere mir also genialer Weise eine Wrapper-Klasse die mir meine Daten die ich übergeben muss in einem IStream-Interface, welches ich mir aus der Erzeuger-Klasse in C++ holen kann, einpackt.

Die Erzeuger-Klasse selbst ruft dann beim eigentlichen Erstellen des COM-Objektes eine Methode in diesem IStream auf die "RemoteRead" heisst und jetzt zerschiesst sich meine Anwendung, weil eigentlich müssten durch diesen Methodenaufruf bis zu 8000 Character gelesen werden, aber die Methode (so wie sie in "IStream deklariert ist") lässt als Rückgabe-Wert nur 1!!! Byte zu.

Nun also meine Frage an die Community ...

Hat schon mal jemand mit IStream's was zu tun gehabt oder kann mir sonst in irgeneiner Weise helfen?

:(

[Manfred.Becker]

Hi HuDeanY,

ich selbst hatte zwar unter C# noch nichts mit IStream's zu tun, jedoch auf meiner Lieblingsseite hab ich folgendes gefunden:

How to Pass Managed Objects As a Parameter of a Queued Component.

Ich hoffe das hilft dir weiter...

[HuDeanY]

Coole Seite zwar ... aber echt weiterbringen tut sie mich auch ned.

Speziel die IStream Problematik taucht da ja auch nirgends auf ... Parameter an und für sich zu Übergeben ist nicht das Problem.

Das was ich eigentlich nicht verstehe ist die übergabe dieser Bytes die ja so ungüsntig eingeschränkt wird ... die methode "Read" macht das ja auch nicht. nur "RemoteRead" macht da so zicken.

[Manfred.Becker]

Hi,

anhand der Beschreibung des Interfaces zu meinem Link dachte ich das wäre was für dich:

  Zitat

Interfaces

The IPersistStream interface provides methods for saving and loading objects that use a simple serial stream for their storage needs. The IPersistStream interface inherits its definition from the IPersist interface, and so includes the GetClassID method of IPersist. The interfaces are defined in objidl.h. To implement IPersistStream in our class, we need to define it in our project first. In the native code, the Load and Save method of IPersistStream takes IStream as input parameter. Its equivalent in managed world is UCOMIStream.

Aber von welcher Klasse kommt denn die Methode RemoteRead(). Darüber kann ich überhaupt nichts finden.

[HuDeanY]

Das ist genau der Punkt an dem ich auch verzweifel ... zur Methode "RemoteRead" gibts weniger als nullo infos ... ausser dass ich sie nicht nutzen soll ... tu ich ja auch ned ... weil das Environment mir ja jeden Aufruf von "Read" aus COM auf die .Net Methode "RemoteRead" umsetzt. Darf es ja auch ... wenn es nur annähernd das gleiche machen würde ...

Read liefer ein Byte[] zurück Remote Read nur ein Byte

ich hasse es ... am ende ist das ganze nur wieder ein Fehler im Framework den ich in meinem Project iiiirgendwie hinbiegen muss.

Jetzt bastel ich am COM Object rum das das den Read aufruf dann eben mehrfach macht (je byte ... ca 8000 mal) und ich dementsprechend einen zeiger laufen lasse was von meinem String in der WrapperKlasse schon gelesen wurde ... zum Glück wird der ganze String nur einmal übertragen.

ICH WILL WIEDER JAVA DA GAB'S SON MIST NED!!!!