Calling native COM from VB 1

[jmaster3]

I don't know if this is the correct forum for my problem. I have a need to call a native COM component (no ActiveX, automation, OLE, etc.) from VB. Is there anybody out there who knows if it can be done, and how?

 

[jmarler]

ActiveX and COM are essentially the same thing. COM is, by its definition, language independent, so all you should have to do (assuming that your "native COM" object is really a COM object that exposes public interfaces) is reference the library from within VB and then make you method/attribute calls.

- Jeff Marler

http://www.JeffMarler.com

(please note, that the page is under construction)

 

[jmaster3]

Hi Jeff

Unfortunately ActiveX and COM aren't the same thing - COM does not necessarily expose an automation interface which is required by ActiveX and it is this automation interface that VB uses. This is my problem. It is easy to use the automation interface, but what do I do when it isn't available?

 

[jmarler]

Hmmm . . . I guess that I was not aware that ActiveX components exposed public Interfaces needed by VB that were not exposed by COM objects . . . what is the name of the Interface that you need to access? - Jeff Marler

http://www.JeffMarler.com

(please note, that the page is under construction)

 

[flaubert]

Whoa!

Ok, forget definitions of COM and ActiveX. Jeff is correct - they are essentially the same thing. You say you need to access a "native" COM component. I'm not sure exactly what you mean by that, but here goes anyway:

A COM component is defined as one that implements the IUnknown interface. This interface contains 3 methods:

AddRef
Release
QueryInterface

Using the QueryInterface method, the object can be queried to find out what interfaces it implements (other than IUnknown). Here's the catch - you cannot call this method directly in VB. It is called indirectly all the time, but you have no control over this.

All objects you create in VB implement dual interfaces (what I think you are calling automation interfaces) - that is, they all implement IUnknown AND another interface called IDispatch, as well as an interface defined by you as the programmer. IDispatch contains four functions which effectively enable VB to find out what methods and properties are supported by an object, and call them. This is what enables late binding in VB.

The upshot of all this is that VB likes objects with dual interfaces - if an object does not implement a dual interface, YOU CANNOT CALL IT FROM VB. You simply can't. VB has no way of finding out what properties and methods the object supports - either at design or runtime.

Now, there aren't many components that do not implement IDispatch - although they do exist. If this is the case, then you are out of luck, I'm afraid. You will have to use another language, such as C++, to use this object.

If, however, your component DOES support a dual interface, then you can use it, but be aware that you may have to create a type library for it first if one does not already exist.

I hope that at least some of this answers your question.

 

[jmarler]

flaubert,
If you are using a COM component (that does not implement the Idispatch interface) in VB and are accessing it using early binding, don't you essentially bypass the IDispatch interface? If this is true AND if you have the TypeLib inforamtion for the COM component (so that you already know the DispIDs), why couldn't you just reference that TypeLib and then use a component that does not support IDispatch? Of course, I realize that if early binding (in VB) still uses IDispatch somehow that this won't work.
- Jeff Marler

http://www.JeffMarler.com

(please note, that the page is under construction)

 

[flaubert]

OK, this is all getting very confusing now! Sorry Jeff, you are of course right - if you have a type library then VB CAN access the object (although the TypeLib will need to contain the vtable for the object, not the DispIDs). If the TypeLib contains just the DispIDs (a dispinterface), then you'll still need IDispatch to call the functions!!!! This is still early binding, but a special case called DispID binding. Fortunately, the type library is probably more likely to contain vtable info, enabling VB to employ the faster vtable binding - hence what you're saying is essentially right. (Please forgive me if I'm teaching you to suck eggs here).

When I said, "if an object does not implement a dual interface, you cannot call it from VB", I meant to say "if YOUR object". I was referring to the mythical object that jmaster3 is talking about, and I was also assuming that he/she has no type library. I was assuming this because if the object (dll?) had one built in, then one would assume that this question would not have been asked, (add the dll into Project, References, and off you go...) and if the TypeLib was stored separately, then one would assume that jmaster3 would know about it, as this is not very common. In the absence of a type library AND an IDispatch interface, VB is, as I say, helpless, and in this situation I would suggest that so would I be, as I certainly cannot think of any easy way to create a type library given this starting point.

Note that if you do have an object that has a type library, with a vtable definition, and no IDispatch interface, then you are faced with the interesting situation of an object to which you can ONLY early bind!

Well, this has all been very interesting, but to be quite honest, I'm not even sure if the initial question has been answered!! I can't answer it without more information. What exactly is the problem jmaster3 is having, and what is the object he wants to use.....

 

[jmarler]

flaubert,
Thanks for the info and the detailed explanation! You are, of couse, correct when you mention that the TypeLib contains the VTable which is used in early binding. Great information!

- Jeff Marler

http://www.JeffMarler.com

(please note, that the page is under construction)

 

[jmaster3]

Jeff and flaubert
I guess it is time I responded to all the excellent discussion that has been going on. My object does not implement a dual interface, and I don't have a typelib for it, so I am in the predicament that you two have spelt out very clearly. For a work-around I got a colleague to build a C++ wrapper that can talk to the object, and also exposes the dual interface which I can access from my VB program. In time, we will change the original object to implement the dual interfaces.
The discussion addressed exactly my problem while providing a vast amount of additional relevent information.
Thanks again!

 

[dswift]

Spotted some serious discussion on IDispatch and wondered if any of you superusers could shed any light on a problem I have. -

The following code works on Windows 95 but gives this error on Windows XP - 'OLE IDispatch exception code 4096 from Microsoft Outlook.' Basically the code (just an extract shown) creates a list of all Apointments or Events in a Visual Foxpro list, that fit a particular type i.e. all those withe the mileage field set to 1-202 or whatever.

It works except for the find line. I can add a Task or an appointment OK.

The line that fails is shown in capitals.
Can any of you help?


objOutlook = createobject ('Outlook.Application')
objNamespace = objOutlook.GetNamespace('MAPI')

*Attempt to get Outlook Actions where [mileage] contains client and matter number

*set up the search clause for example "[mileage] = '1-202'"

myclause="[mileage] = '"+alltrim(curcli)+"-"+alltrim(curmat)+"'"

LOITEM=NUMITEMS.FIND(MYCLAUSE)

do while isnull(loitem)=.F.
x=x+1
Myitem=loitem
* Myitem.display

outlst(x,1)=Myitem.billinginformation
outlst(x,2)=Myitem.subject
outlst(x,3)=Myitem.start
outlst(x,4)='None'
outlst(x,5)=Myitem.body
if Myitem.alldayevent=.t. Then
outlst(x,6)='Event'
else
outlst(x,6)='Appointment'
endif

loitem=numitems.findnext
enddo

 

[DKL01]

Hi,

Where can I get the detailed information about vtable and typelib ? Does VB create typelib and vtable when we create ActiveX DLL ?

Thanks

 

[strongm]

Generally in VB you do not need to worry about vtables.

As for typelibs, VB does not create them.