ich möchte gern aus einer COM-DLL heraus eine Callback-Funktion eines Clients aufrufen. Der Aufruf soll aus einer in der DLL implemenierten Klasse heraus erfolgen. Mir fehlt da aber irgendwo der richtige Input an Wissen. Meine beiden Hauptprobleme sind:

1. Wie übergebe ich den Funktions-Zeiger aus dem Client an die COM-DLL? (Interface-Definition?)
2. Wie binde ich diesen Funktionszeiger in der DLL-internen Klasse dann ein, damit ich darüber die Callback-Funktion des Clients aufrufen kann?

Ich arbeite unter Visual Studio 2005 (VC++). Die Callback-Funktion des Clients hat folgendes Aussehen:

void CKlasse::Callback(LPVOID pContext, TMyStruct* pMsg);
(TMyStruct ist dabei allerdings in der DLL definiert)

Hat jemand einen Tipp, eine Website oder eine Buchempfehlung, wo soetwas abgehandelt wird? Oder kennt sich jemand damit soweit aus, um hier eine kurze Beschreibung posten zu können?

Für jegliche Hilfe schon im Voraus vielen Dank!
Wes

Das Grundprinzip ist auf jeden Fall immer dass du dem COM Objekt ein Interface mitgibst, also z.B.:

interface XYZ ...
{
...
    HRESULT SetCallback([in] IMyCallBackInterface* p);
};

Im Falle von IConnectionPoint heisst die "SetCallback" Funktion dann eben Advise und liefert über ein output Parameter noch ein Cookie zurück welches die "connection" identifiziert. Was der eher lästige Teil bei IConnectionPoint ist ist die Implementierung von IConnectionPointContainer.
Du kannst dir aber zum Testen mal ein Projekt mit attributed COM machen, dort dann einfach __event verwenden, und gucken was der Compiler für Code generiert.
Ich denke sogar es sollte da in der ATL bereits irgendwelche Klassen geben die einem den Grossteil der Arbeit abnehmen.

Falls du es mit Hand machen willst: die SetCallback von oben müsste dann einfach nur ein AddRef auf das übergebene Interface machen, und den Pointer irgendwo ablegen.
Falls dein COM Objekt single threaded ist und du aus einem Thread heraus Events verschicken willst musst du den Zeiger allerdings erstmal in diesen Thread rübermarschallen. Das gilt zwar grundsätzlich immer wenn ein Interface-Zeiger zwischen zwei Apartments übergeben wird, ich erwähne es nur falls du mit sowas noch nie zu tun hattest.

Werd mich jetzt erst mal in den ersten Tipp reinwühlen und melde mich dann ggf. nochmal falls die Probs zu arg werden.

Besten Dank erst einmal,
Wes

Und nein, mein COM-Objekt arbeitet mit einem weiteren von ihm gestarteten "Horch"-Thread, aus dem heraus dann auch die Callback-Funktion aufgerufen werden soll.

Wie, nein? Genau das meine ich ja, ein eigener Thread der die Events erzeugt.
In dem Fall musst du das Interface "marshallen", es sei denn das COM Objekt verwendet das MTA Modell ("multithreaded apartment"), dann erledigt das COM Subsystem ggf. das nötige Marshalling für dich.

Verwendet das COM Objekt allerdings das "STA" Modell ("singlethreaded apartment") darfst du auch outgoing Interfaces (also das was du vom Client bekommst) nur von dem Thread aus verwenden mit dem dein COM Objekt angelegt wurde, also eben nicht vom "Event Thread" aus.
Die IMHO einfachste Lösung in so einem Fall ist das Interface über den GIT zu marshallen: http://msdn2.microsoft.com/en-us/library/ms693781.aspx
Ansonsten kannst du CoMarshalInterThreadInterfaceInStream verwenden: http://msdn2.microsoft.com/en-us/library/ms693316.aspx

Daneben habe ich noch eine Frage am Rande. Mehrere Prozesse werden jeweils gleichzeitig einzelne Instanzen des COM-Objektes nutzen. Allerdings werden dabei auch shared Variablen benötigt, die von allen Instanzen (nur intern) gleichermaßen genutzt werden. Ist das auch einfach mit #pragma data_seg zu realisieren oder sind da bei COM-DLLs noch andere Besonderheiten zu beachten?

Danke für die Mühe,
Wes

Allerdings wäre es wohl einfacher das ganze als COM Server (.exe statt .dll eben) zu realisieren, dann brauchst du auch kein shared data Segment.
Der grosse Nachteil von COM Servern ist allerdings dass die Aufrufe viel viel länger dauern. Wenn du so mit max. 1000 Calls pro Sekunde rechnest sollte es auf heutigen Rechnern egal sein. Wenn du mit deutlich mehr rechnest scheidet der COM Server wohl aus, bzw. würde u.U. einiges an Overhead erzeugen. Hier hilft natürlich ausprobieren

Nochwas: probier auf jeden Fall auch die Client Seite aus bevor du dich für ein MTA entscheidest.
Ich weiss nurmehr dass es Probleme gibt wenn der GUI Thread in einem MTA ist und man ActiveX GUI Komponenten verwenden will - das geht dann nämlich nicht.
Also steckt man den GUI Thread wohl oder übel in ein STA. Dass deine Komponente dabei MTA ist *sollte* egal sein, aber ausprobieren würde ich es trotzdem.

Bei Verwendung eines COM Servers weiss ich dass es egal ist, das habe ich selbst so im Einsatz.

Und die wunderbare Terminologie: InProc, OutProc, STA, MTA, ...
Und ganz toll sind die Enum interfaces und nätürlich immer wieder einmal
aus langeweile einen RPC mechanismus zu schreiben, der vollkomment transparent
arbeitet, Wundebar!!

(Das ist wirklich ernst gemeint)

__interface IUseless : IUnknown
{
    STDMETHOD(DatIsDoll)(ULONG* pulPar1, REFIID riid);
};

class UselessObject : public IUseless
{
public:
    UselessObject();
    ~UselessObject();
public:
    // IUnknown
    DECL_UNK
    // IUseless
    STDMETHOD(DatIsDoll)(ULONG* pulPar1, REFIID riid);
private:
    ULONG m_Ref;
};