Pointer ohne Member

EOutOfResources

Du weist es mal wieder besser, aber OK. Nein! ISO-C++ kennt die Präprozessordirektive "import" nicht (was eigentlich schon oft genug erwähnt wurde! Und nein! Ohne Header keine DLL!

CStoll

IceRage schrieb:

EOutOfResources schrieb:

IceRage schrieb:

Also 1. hatte ich ZU ihm Kontakt, und nicht MIT ihm. Das solltest du verstehen können.

Wenn wir schon soweit sind: DLL ist eine englische Abkürzung, also entweder alles gross oder alles klein schreiben.

Sagt mal habt ihr beiden Honks auch noch inhaltliche Beiträge zu liefen, ganz ohne Herabwürdigungen, in neutraler Weise, zielführen und hilfreich, was eigentlich die Qualität eines solchen Forums ausmacht?

Ich habe ja schon viel erlebt, in vielen Foren. Aber das ein Moderator und ein Hilfshonk sich derart vergehen ist mir echt mal was ganz Neues. Gewöhnlich ignoriere ich Deppen wie euch einfach, und hoffe auf hilfreich gemeinte, inhaltlich orientierte Beitrgäge. Aber scheinbar gehören Verfasser derartige Beiträge hier zur Liste der Mangelexemplare.

Also das nehme ich jetzt persönlich. Ich weiß selbst recht gut, wann ich mit meinem Wissen am Ende bin, deshalb wollte ich mich eigentlich aus dem weiteren Thread heraushalten.

Also falls sich hier noch jemand inhaltlich mit der Problematik befassen möchte, bin ich gern dabei. Alles Weiter geschwafel ignoriere ich ab jetzt. Was natürlich nicht die inhaltliche Aussagen bisher einschließt. Somit kommt man zu der Frage: Warum wurde keine Headerdatei bei Redemption mitgeliefert? Geht es also auch ohne Headerdatei, oder nicht???

Sorry, so gut kenne ich mich weder mit COM noch mit Redemption aus, um diese Frage zu beantworten. Ich weiß nur, daß ein normaler C++ Compiler erwartet, daß du ihm erklärst welche Datentypen du benötigst und wie diese aussehen. Wie du das Problem ohne einen Header lösen kannst, wissen wohl nur die Leute, die diese DLL entwickelt haben.

EOutOfResources

IceRage schrieb:

Kann man am Ende Redemption gar nicht in C++ verwenden, weshalb auch die Pointer ins Leere laufen???

Mit mehr Fragezeichen geht es nicht besser! Du kannst keinen Zeiger auf einen nichtexistierende Typ machen! Er wird auch nicht "ins Leere laufen" wie du es nennst. Er kann schlicht und einfach nicht erzeigt werden!

hustbaer

@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.

C++ Forumbot

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.

IceRage

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.[...]

IceRage

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!

weicher

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

IceRage

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

weicher

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

IceRage

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.

Martin Richter

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/

weicher

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

IceRage

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.