Non-ATL COM DLL in Excel nutzen?

SeveQ

Hallo Leute,

bin neu hier und hoffe, ich bin hier richtig und es kann mir hier jemand bei meinem Problem helfen:

Ich implementiere einen OLE DB Provider, den ich gern in Excel ansprechen würde. Die Bibliothek dafür wird ohne ATL kompiliert, da sie auf einem Beispielprojekt basiert, das ebenfalls komplett ohne ATL entwickelt wurde. Versuche ich nun, jene DLL im VBA von Excel als Verweis einzutragen, erhalte ich lediglich die Fehlermeldung, der Verweis auf die angegebene Datei könne nicht hinzugefügt werden.

Füge ich die zur DLL zugehörige TLB als Verweis hinzu, akzeptiert VBA dies, liefert mir auch die von mir in der IDL defininierten Schnittstellen, Klassen und Methoden. Aber ich kann sie nicht aufrufen. Erstellen eines Objektes einer der exportierten Klassen funktioniert noch. Aber der Aufruf einer Methode des Objektes führt zum Laufzeitfehler '91': Objektvariable oder With-Blockvariable nicht festgelegt. Mein VBA Code sieht so aus:

Sub test()
  Dim a As CCommand
  a.FInit
End Sub

Wobei CCommand eine der exportierten Klassen ist (gehört zum OLD DB Provider) und FInit eine der Methoden der Klasse CCommand.

Was muss ich mit einem reinen DLL Projekt (ohne MFC, ATL etc.) noch anstellen, um es in VBA nutzen zu können?

Danke!

Grüße,
Hendrik

EDIT: Zu spezifisch die Frage???

Hi,

Das erste was ich bei einer "selbstgestrickten" COM-Dll testen würde wäre:

- Hast du sichergestellt, dass die DLL korrekt registriert ist (sprich von ProgID über InprocServer32 bis CLSIDs und IIDs etc....) alles samt Pfaden und GUIDs in der Registry steht wo es soll?

- die DLL die ClassFactory und IDispatch Schnittstelle korrekt implementiert?

- Die notwendigen COM Funktionen von RegisterServer bis DllCanUnloadNow etc. von der DLL exportiert werden?

- Die Aufrufkonventionen der exporierten Funktionen korrekt sind?

- Die tlb scheint ja korrekt zu sein, solltest den MIDL Code und die generierten Dateien aber trotzdem mal im Detail checken, (nur wenn alles andere richtig sein sollte ...)

Wenn alles richtig ist, solltest Du mal eine Debugversion der Dll erstellen und checken, ob z.B. die Dll überhaupt geladen wird, ob die exportierten Funktionen aufgerufen werden etc., evtl. macht Excel hier auch ein paar unkonventionelle Aufrufe mit der Dll ... wäre nicht der erste Fall.

p.s. es gibt gute Tutorials für sowas im Netz, mehr würde hier jeden Rahmen sprengen

Sorry ich seh gerade, dass CCommand eine Klasse ist ...

Mann, das kann nicht gehen! Du bist in VB und das kennt keine C++Klassen und C++Aufrufkonventionen, geschweige denn kannst Du eine Klasse per COM exportieren.

COM geht ausschließlich über Schnittstellen, besorg Dir erstmal ein Tutorial bevor Du eine eigene COM-Dll schreibst.

Viel Erfolg

hustbaer

Äh.
"Dim" erstellt doch noch kein Objekt, bloss eine Referenz... zzz.

SeveQ

Sorry, ich komme aus der .NET Schiene, und dort ist das alles sehr viel einfacher.

Die Exports sind alle soweit in Ordnung. Irgendwie muss VBA aber dennoch in der Lage sein, mit den Klassen von C++ umzugehen, da ich ja per Dim eine Referenz auf solch ein Objekt anlegen kann. Das funktioniert ja nicht nur mit der selbstimplementierten Klasse, sondern auch mit anderen Klassen aus DLLs. Die Dinger sind ja als Co-Class über die IDL exportiert.

Deswegen... es wundert mich, daß die TLB funktioniert (zumindest für Intellisense und den Objectbrowser in VBA), die DLL aber nicht. Woran kann das noch liegen?

Die Klassensammlung die hier für VBA zugreifbar gemacht werden soll, stammt aus einem Beispielprojekt für einen OLE DB Provider. Sie ist nicht selbstimplementiert.

hustbaer

Nochmal: es funktioniert nicht weil du mit "Dim bla as blubb" bloss eine Referenz anlegst, aber noch kein Objekt. Du musst noch irgendwoher dein Objekt bekommen - eben irgendwas ala "Set bla = New blubb" oder so ähnlich machen.
Ist in C# oder VB .NET auch nicht anders.