4. Pointer ohne Member

Pointer ohne Member


  • @IceRage: du bist im falschen Forum. Hier ist das (ISO) C++ Forum. Dein Thread gehört ins MFC/Visual C++ Forum, da sich deine Frage um MSVC-spezifische Extensions dreht.

    #import ist eine MSVC-spezifische Extension. Dabei wird ein Type-Library File, oder auch eine .DLL mit "eingebauter" Type-Library geparsed, und automatisch die darin definierten COM Interfaces definiert. Zusätzlich werden Wrapper-Klassen erstellt die z.B. COM Properties als "Properties" (eine weitere MSVC-spezifische Extension) der Wrapper-Klassen erscheinen lassen.
    Die Wrapper-Klassen machen auch aus COM Error-Codes Exceptions ( _com_error ).

    Und für COM Klassen die nur eine IDispatch Schnittstelle anbieten (also keine "normalen" Interfaces implementieren) werden - wenn ich mich richtig erinnere - auch entsprechende Wrapper-Klassen definiert.

    Die #import Direktive sieht OK aus.

    Was nicht mehr OK aussieht ist dieser Teil hier:

    HRESULT hr = CoInitialize(NULL); 
    CLSID clsid; 
    Redemption::RDOSession *session; 

    hr = CLSIDFromProgID(OLESTR("Redemption.RDOSession"), &clsid); 
    hr = CoCreateInstance(clsid, NULL, CLSCTX_INPROC_SERVER, IID_IUnknown, (LPVOID*)&session);

    Das müsste IMO so aussehen:

    HRESULT hr = CoInitialize(NULL); 
    Redemption::RDOSessionPtr session(L"Redemption.RDOSession");

    Danach solltest du mit session->Foo() deine Funktionen aufrufen können.
    Bin mir aber nicht 100% sicher, schon zu lange her dass ich ne Type-Library mit reinen Dispatch-Interfaces mit #import verwendet habe.

    Ansonsten guck dir die (beim compilieren) generierten .tlh und .tli Files an. Die sollten im Debug bzw. Release Verzeichnis zu finden sein, bzw. halt dort wo die ganzen .obj Files liegen.
    Da drinnen siehst du welche Klassen MSVC in der DLL gefunden hat, wie sie heissen, welche Member-Funktionen sie haben etc.

    0
  • C

    Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x) in das Forum MFC (Visual C++) verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • I

    hustbaer schrieb:

    @IceRage:
    Was nicht mehr OK aussieht ist dieser Teil hier:

    HRESULT hr = CoInitialize(NULL); 
    CLSID clsid; 
    Redemption::RDOSession *session; 
     
    hr = CLSIDFromProgID(OLESTR("Redemption.RDOSession"), &clsid); 
    hr = CoCreateInstance(clsid, NULL, CLSCTX_INPROC_SERVER, IID_IUnknown, (LPVOID*)&session);

    Das müsste IMO so aussehen:

    HRESULT hr = CoInitialize(NULL); 
    Redemption::RDOSessionPtr session(L"Redemption.RDOSession");

    Danach solltest du mit session->Foo() deine Funktionen aufrufen können.
    Bin mir aber nicht 100% sicher, schon zu lange her dass ich ne Type-Library mit reinen Dispatch-Interfaces mit #import verwendet habe.

    Ansonsten guck dir die (beim compilieren) generierten .tlh und .tli Files an. Die sollten im Debug bzw. Release Verzeichnis zu finden sein, bzw. halt dort wo die ganzen .obj Files liegen.
    Da drinnen siehst du welche Klassen MSVC in der DLL gefunden hat, wie sie heissen, welche Member-Funktionen sie haben etc.

    Das bringt leider auch nicht den gewünschten Erfolg. Kann natürlich auch sein, dass ich da noch etwas anderes flasch mache. Wenn ich RDOSessionPtr verwenden will, dann wird mir über IntelliSence keine solcher Pointer auf eine Klasse angeboten. Außerdem erscheint RDOSessionPtr im Code rot unterstrichen mit dem ToolTip Hinweis: Namespace "Redemption" hat keinen Member ...

    [unsachlich]Ich möchte mal wissen wer so eine sperrige Scheisse programmiert! unfassbar!!! Da funktioniert nichts!!![/unsachlich] 😉

    @hustbaer
    Wenn du noch eine Idee hast, wie der granze Kram doch noch zur Funktion überredet werden könnte, dann versuch ich das gern noch mal. Erstmal vielen Dank für deine Hilfe.

    Evtl. OT:
    Hier noch mal eine Aussage des Entwicklers/Entwicklerteams?, um Redemption. Ich würde das gern hier posten, weil es ja schon in engem Zusammenhang mit dem Threadinhalt steht. Sonst möge man es einfach verschieben.

    Bezüglich der Frage der Header, die von den Beiden hier "gestellt" wurde (Quelle: Email):

    Dmtry Streblechenko schrieb:

    [...]When you use #import to import the Redemption type library, it creates a header file.[...]

    0
  • I

    hustbaer schrieb:

    @IceRage:
    Ansonsten guck dir die (beim compilieren) generierten .tlh und .tli Files an. Die sollten im Debug bzw. Release Verzeichnis zu finden sein, bzw. halt dort wo die ganzen .obj Files liegen.
    Da drinnen siehst du welche Klassen MSVC in der DLL gefunden hat, wie sie heissen, welche Member-Funktionen sie haben etc.

    Das wird mir ja alles über IntelliSence angezeigt. Zumindest gehe ich mal davon aus, dass auch wirklich alles angezeigt wird, was ich nicht 100%ig wissen kann.

    Es tut nur einfach nicht was es soll! Das nervt echt!

    0
  • W

    Hallo IceRage,

    versuch es mal so:

    #import "C:\\Programme\\Redemption\\Redemption.tlb"

    denn der Entwickler sagt:

    When you use #import to import the Redemption type library

    die type library hat aber die extension tlb und nicht dll.

    Herzliche Grüsse
    Walter

    0
  • I

    Die tlb liegt dem Projekt leider gar nicht bei. Ich weiß nicht, ob das der Fall sein müsste damit es nach deinem Vorschlag funktionieren kann, oder ob vs express selbst eine tlb anlegt ... kA leider. Im Order unter Programme zumindest liegt weiterhin ausschließlich die dll Datei. Außerdem bekomme ich leider weiterhin "keine Member vorhanden" angezeigt.

    Trotzdem Danke für deine Hilfe. Vielleicht wirds ja doch noch was. Wobei ich schon ein Beispiel mit Extende MAPI zu verstehen versuche, was scheinbar erfolgversprechender ist, da es besser dokumentiert ist als Redemption.

    Der Entwickler ist scheinbar auch nicht bereit, auch nur ein winziges stückchen Code heraus zu geben. Also hat sich das mit Redemption für mich schon fast erledigt. Wobei man das ja sicher ganz einfach die Beispiele in VB nach C++ übersetzen kann 🙂

    0
  • W

    Hallo IceRage,

    ja, die Redemption.tlb müsste dem Projekt beiliegen. Frag doch den Entwickler danach.

    Der Entwickler ist scheinbar auch nicht bereit, auch nur ein winziges stückchen Code heraus zu geben.

    Das ist eigentlich schon der Sinn der COM Komponenten 😉

    Herzliche Grüsse
    Walter

    0
  • I

    weicher schrieb:

    Hallo IceRage,

    ja, die Redemption.tlb müsste dem Projekt beiliegen. Frag doch den Entwickler danach.

    Der Entwickler ist scheinbar auch nicht bereit, auch nur ein winziges stückchen Code heraus zu geben.

    Ich schreibe den Entwickler deswegen noch einmal an. Mal sehen was sich tut.

    weicher schrieb:

    Das ist eigentlich schon der Sinn der COM Komponenten 😉

    Herzliche Grüsse
    Walter

    Ja eben, deswegen kannst du meine Verwirrung vielleicht auch bezüglich der fehlenden Funktionalität/tlb verstehen ;). Wenn ich was rausgeben, dann sollte man auch damit arbeiten können. So sehe ich das zumindest.

    0
  • Mod

    1. Wenn eine DLL (wie auch die Redemption DLL) eine eingebettete TLB hat, dann kann man auch die DLL beim #import angeben.
    2. Je nach Definitionen wie man den #import mach werden die ..Ptr Wrapper mit erzeugt oder nicht.
    Was erzeugt wird kann man selber kontrollieren wenn man die tlh Datei öffnet, die durch den #inport erzeugt wird.
    3. Ich verwende nur die Raw-Interfaces und die CComPtr etc. aus der ATL..
    4. Ich packe nie die DLL/TLB in das Source-Control System, einmal erzeugte tlh/tli Dateien werden einfach als statische #includes verwendet.
    Siehe auch:
    http://blog.m-ri.de/index.php/2008/08/03/tipps-tricks-import-durch-include-ersetzen/

    0
  • W

    Hallo Martin,

    Wenn eine DLL (wie auch die Redemption DLL eine eingebettete TLB hat, dann kann man auch die DLL beim #import angeben

    Wieder etwas gelernt, Merci.

    Herzliche Grüsse
    Walter

    0
  • I

    Martin Richter schrieb:

    1. Wenn eine DLL (wie auch die Redemption DLL) eine eingebettete TLB hat, dann kann man auch die DLL beim #import angeben.
    2. Je nach Definitionen wie man den #import mach werden die ..Ptr Wrapper mit erzeugt oder nicht.
    Was erzeugt wird kann man selber kontrollieren wenn man die tlh Datei öffnet, die durch den #inport erzeugt wird.
    3. Ich verwende nur die Raw-Interfaces und die CComPtr etc. aus der ATL..
    4. Ich packe nie die DLL/TLB in das Source-Control System, einmal erzeugte tlh/tli Dateien werden einfach als statische #includes verwendet.
    Siehe auch:
    http://blog.m-ri.de/index.php/2008/08/03/tipps-tricks-import-durch-include-ersetzen/

    Also wenn wie du sagst alles komplett ist, warum sind dann die Pointer immer noch ohne Member?

    Noch mal die Frage, warum nicht einfach mal ein Beispielcode gepostet wird, oder zumindest eine Quelle (In C++!) der die Funktionsweise von COM darstellt? Das wäre doch am einfachsten. Welches COM dabei verwendet wird, ist ja vollkommen wurst. Ob es nun gleich Redemption sein muss, oder, um es nicht ganz so einfach zu machen, eben ein anderes COM sollte dann ja egal sein. Wenigstens hier wird man ja wohl von einer einheitlichen Verwendung ausgehen können, auch unter Win.

    0
Anmelden zum Antworten