Interpreting a type library

[the_net_2.0]

hey you gurus,

I downloaded the tlbinf32.dll file and played around with it for a little while. It was interesting to see the hierarchies associated with the office programs.

has anyone else experimented with this? I wrote a small procedure and I found that you can print out classes of objects and stuff. but the object classes have interfaces. it's a child collection. the interfaces have members and parameters of the members. I'm not quite sure what an interface or members mean. If I look at the print out of the loops I see objects and properties/methods, etc... but I also see some weird stuff that I think is internal, because I don't recognize it from my years of working with access through the interface.

does anyone have any knowledge about this sort of thing?

 

[vbaInet]

I haven't used that type library but in OOP terms an interface is just simply a definition of how an object interacts with other objects. It defines the methods with which they do so.

Members are the properties and methods that belong to that object, some of which may be hidden.

 

[the_net_2.0]

I haven't used that type library but in OOP terms an interface is just simply a definition of how an object interacts with other objects. It defines the methods with which they do so.

Members are the properties and methods that belong to that object, some of which may be hidden.

inet,

after some searching and fun little code runs, I found that library files basically have 8 types in them, or can, at the max (I assume). I scanned thousands of them, so I guess I can assume.

thanks for the info!

 

[vbaInet]

I haven't delved into that area of vba. It's too low level for me to bother so I'm not sure about how many types a library in vba can have.

Sounds like you're having fun there

 

[Banana]

As a FYI:

There are several objects we may be working that are not actually classes but interfaces. It's just that VBA makes no distinction between a "class" and an "interface". Recordset object is an example of where there is no such thing as "Recordset Class" (at least not for DAO - there is one for ADO, though). This is just a educated guess but I believe that Recordset interface comes from the same object that represents a TableDef class or QueryDef class.

As mentioned, Interface is basically a contract that promises that a X object is capable of doing so and so and can be shared by several classes. This is distinct from inheritance in that you can have two wildly different classes that would not be a part of the same parentage but apply same interface and voila, you can know that both classes can be used to do something same.

A good tool to browse all those details is to use oleview.exe which I believe comes with a Visual Studio installation (I don't know if it comes with an Express installation?). It'll also show how different languages outside the VBA will perceive the classes/interfaces because they don't have to work within COM whereas VB/VBA must owrk within that constraint.

I hope that helps a bit...

 

[the_net_2.0]

yes guys,

that all helps. Interesting info too. thanks!

and Banana, if you loop the types from olb's and dll's, you can plainly see that classes and interfaces are basically the same. IMO, it's not understandable. There really should be more distinction between these two things. Another interesting thing about it is that classes don't have members, but the interfaces of the classes DO.

then if you compare an interface, specifically the one that is on the same level as a class (not the level that's one lower, as I mentioned above), to a class, it has members (methods and props) even through its basically the same entity as a class, especially when it appears in the intellisense. looking at intellisense in that context, it is impossible to know which is which. but at that level, it doesn't really matter!

and if I may ask one more question Banana, in your opinion, where does the word "component" fit into the vba, or even vb language? How does the COM differ from other models?

 

[Banana]

The reason behind the difference in class/interface is all about COM, really. Component Object Model is simply a framework describing how objects should be built so it can be reusable by any consumers. In very loose manner of speaking, you could say COM is basically the ODBC of programmatic objects. It's just that as part of the design, Microsoft built VB6 and VBA atop the COM level so that's why every Visual Basic object are COM object by implication and also explain why sometimes it may be difficult to use non-COM objects inside VB/VBA (e.g. some API functions that uses some exotic C++ sleight of hand that would be incompatible in COM context).

The important thing to understand about COM is that everything are presented as an interface; when we pass a COM object to another process, we are actually handing a pointer to an interface. This is why you have to use interfaces to see members; again, inside the VB/VBA context there is no distinction between an interface and a class but interface is the only thing COM will know about and therefore can pass along.

Next, COM has 2 standard interfaces that are always associated with various COM objects; IUnknown and IDispatch. IIRC, all must have IUnknown interface but to support early binding, IDispatch is also needed. Those are the interfaces that makes it possible to share COM object between different processes that may not otherwise know or understand - With IDispatch interface, VBA (as an example) is able to enumerate all available members of say, Excel Object Library and therefore list them in the intellisense. There is also one more kind of interface that's not directly used; SoureInterface which is basically how we handle the events. If you look carefully, you'll see that events for various objects are in a separate interface (e.g. FormEvents as example) but in the VBA context, we see them as one object essentially.

If you want to know more, that would be a good place to start.