Suche Einführung in DCOM
-
Wenn du es wirklich ernst meinst, wirst um spezielle Literatur nicht herumkommen. Im Internet hab ich noch nix gefunden, was COM einigermassen anschaulich erklaert und nen Einstieg in gewisse Probleme gibt. Im Internet ist alles entweder a: viel zu oberflaechlich, b: zu spezialisiert c: Informationen zu zerstreut.
Gute Literatur:
Inside Com+
Inside ATL
beides von M Literatur ansonsten nicht so prickelnd finde, die Buecher haben mir echt weitergeholfen. Gibt aber sicher auch noch andere ...Dummerweise gibt es Deppen, die über IClassFactory::CreateInstance tatsächlich das gleiche Objekt zurückgeben
Dann nutzt du aber deren ClassFactory ? Normal schreibst eh immer deine eigene, wenn du schnell oder bei gewissen sachen besonders intsanziieren willst. Ansonsten Machst doch CoCreateInstance direkt auf die Schnittstelle und Windows benutzt die Standard Class Factory ... = Immer neues COM Object !
ciao ...
-
RHBaum schrieb:
Ansonsten Machst doch CoCreateInstance direkt auf die Schnittstelle und Windows benutzt die Standard Class Factory ... = Immer neues COM Object !
Genau so will ich das auch. CoCreateInstance = Neues Objekt. Und jetzt schaust Du mal in das von Dir erwähnte Buch "Inside COM+" auf Seite 361. Und schon hast Du das alles schöne ausgehebelt. Wer sich nun, berechtigterweise, auf ein neues Objekt verlässt, bekommt unter Umständen Probleme. Und nur weil das bei der GIT ebenso ist, wird das nicht richtiger.
-
Urks ok, das ist natuerlich boese
Normal laesst man auch die Standard ClassFactory, und kreirt ne spezielle am CLient, wenn man braucht.Aber wer das da umklemmt wird schon wissen warum ers tut. Wenn 2. Instanzen probleme machen ... ists doof.
Auf der anderen seit sollte CoCreateInstance wirklich immer ne neue Instanze liefern. Aber ohne CoCreate geht das new in den ScriptSprachen wieder nicht. Was ein Verlust !
Normal wuerde man das mit nem Handler Realisieren, und die eigentliche Problematische COM Klasse NO_CREATIABLE machen. Dann musst den Haendler konsultieren nach deiner Instance mit ner Get_Methode holen.Also ich denk mal, das man sich in deinem Fall wirklich nur arbeit ersparen wollt ... Naja, und M$ behandelt das Kapitel auch nur ganz kurz ... ohne auf andere Bessere Wege wirklich hinzuweisen.
Ciao ...
-
RHBaum schrieb:
Normal laesst man auch die Standard ClassFactory, und kreirt ne spezielle am CLient, wenn man braucht.
Was ist eine Standard ClassFactory? Warum soll der Client die ClassFactory implementieren?
Aber wer das da umklemmt wird schon wissen warum ers tut. Wenn 2. Instanzen probleme machen ... ists doof.
Wenn 'er' das umklemmt und 'er' weiß was er tut, ist's ja schön. Aber was ist mit dem Anwender? Weiß der auch, wie das Objekt implementiert ist? Soll und muß der das wirklich wissen? Da wird's in der Tat ganz schnell ganz doof.
Auf der anderen seit sollte CoCreateInstance wirklich immer ne neue Instanze liefern. Aber ohne CoCreate geht das new in den ScriptSprachen wieder nicht. Was ein Verlust !
Das muß nicht sein. Da gibt es Mittel und Wege das vor dem Anwender zu verbergen, da geht dann nichts verloren. Das ist aber vom Verwendungszweck des Objects abhängig.
Normal wuerde man das mit nem Handler Realisieren, und die eigentliche Problematische COM Klasse NO_CREATIABLE machen. Dann musst den Haendler konsultieren nach deiner Instance mit ner Get_Methode holen.
Das ist beispielsweise eine gute und saubere Möglichkeit. Der get_Methode gleich noch einen Namen mitgegeben und schon kannst Du sogar ganz bestimmte Objekte anfordern; das ist ein rieseger Gewinn!
Also ich denk mal, das man sich in deinem Fall wirklich nur arbeit ersparen wollt ...
Ja, das sehe ich auch so. Unterm Strich ist das aber trotzdem große Sche*sse.
Naja, und M$ behandelt das Kapitel auch nur ganz kurz ... ohne auf andere Bessere Wege wirklich hinzuweisen.
Das ist leider richtig.
-
Teilweise hab ich da jetzt nur Bahnhof verstanden, so tief bin ich in dem Thema noch nciht drin *g*
Vielleicht schreib ich einfach mal, was ich genau haben will:
Ich möchte, daß Plugins, die in mein Programm geladen werden, über eine Schnittstelle auf das Hauptmodul zugreifen können um darin bestimmte Funktionen aufrufen zu können. Da das Hauptprogramm nur einmal läuft, dachte ich mir, wäre es vielleicht sinnvoll wenn es auch nur eine einzige Schnittstelle dorthin gibt. Bei DirectX z.B. hatte ich das zumindest auch so verstanden, daß es jeweils nur eine Schnittstelle IDirect3D9 usw. gibt.
Was wäre eurer Meinung nach die sinnvollste bzw. sauberste Methode das zu lösen? Alles, was nur einmal vorhanden sein soll, als globale Variable in der DLL bzw. static-Variablen in der Klasse zu implementieren? Oder gibts da noch etwas besseres?Danke auch für die Buchtipps. Werde mich mal danach umsehen.
-
Baldur schrieb:
Alles, was nur einmal vorhanden sein soll, als globale Variable in der DLL bzw. static-Variablen in der Klasse zu implementieren?
Bitte keine globalen Variablen! Deine Anwendung wird das PlugIn sowieso nur einmal laden. Dann kannst Du die Variablen auch dem Objekt zuordnen.
Zugriffe auf globale Variablen müssen synchronisiert werden, selbst wenn Du das ThreadingModel auf Apartment setzt. Wenn Du da nicht dran denkst, wird das unter Umständen ganz schnell ganz gefährlich.
Aber lese ruhig erstmal ein Buch. Das wird Dich jetzt am Meisten weiterbringen.
-
Irgendwie steck ich nun gerade in einer Sackgasse.
Ich habe ein Interface IMainModule, das die zentrale Schnittstelle in der Anwendung darstellen soll. Alle Plugins, die die Schnittstelle verwenden, müßten also auf die selben Daten zugreifen können.
Ich wollte nun zuerst eine Funktion in der DLL exportieren, die mir einmal das Interface erstellt und dann bei jedem Aufruf den Zeiger darauf zurückgibt. Nur brauche ich dazu ja auch wieder eine globale Variable, in der ich den Zeiger speichere...
Wäre hilfreich, wenn du mir einen Tip geben könntest, wie ich das am besten löse
Das Buch ist leider noch nicht da
-
So, bin auch wieder da, war im Urlaub
Nur brauche ich dazu ja auch wieder eine globale Variable, in der ich den Zeiger speichere...
-King- deutete schon auf die GIT (IGlobalInterfaceTable) hin, und diese musst Du auch verwenden. Den zurückgegebenen DWORD-Wert kannst Du dann natürlich speichern.
Bei der GIT geht es darum, dass Schnittstellenzeiger nicht einfach so weitergegeben werden dürfen (Apartmentwechsel, neuer Thread, Threadsicherheit, Marshaling).
-
RenéG schrieb:
So, bin auch wieder da, war im Urlaub
Und gleich am ersten Arbeitstag schon vor 10 wieder im Büro. Das muß ja ein Urlaub gewesen sein ...
@Baldur
Ein andere, eventuell soagar einfachere, Option führt über IObjectWithSite. Wenn Dein IMainModule nun das Plugin lädt, besorgt es sich zunächst einen Pointer auf diese Schnittstelle (die das Plugin nun auch implementieren muß). Über IObjectWithSite::SetSite kannst Du den Unknown-Pointer zu Deinem IMainModule übergeben. Das Plugin kann sich den Pointer dann aufbewahren (natürlich erst nach dem AddRef).Wenn der Unknown-Pointer aber in mehreren verschiedenen Threads Verwendung finden soll, ist auch meiner Meinung nach die GIT das Mittel der Wahl.
-
Und gleich am ersten Arbeitstag schon vor 10 wieder im Büro. Das muß ja ein Urlaub gewesen sein ...
Hat nix mit dem Urlaub zu tun, ich muss einfach spätestens 8Uhr da sein, hab aber den Wecker fast kleingehauen