3

How can I, for any two given objects, determine at runtime whether those two objects implement the same interface?

Given an interface IStackExchange and the two classes StackOverflow and CodeReviewSE that both implement IStackExchange, I know I can do stuff like this:

Dim SO As IStackExchange
Dim CRSE As IStackExchange
Set SO = New StackOverflow
Set CRSE = New CodeReviewSE

Debug.Print TypeName(SO)                    ' StackOverflow
Debug.Print TypeOf SO Is IStackExchange     ' True
Debug.Print TypeOf SO Is StackOverflow      ' True
Debug.Print TypeOf SO Is CodeReviewSE       ' False

Debug.Print TypeName(CRSE)                  ' CodeReviewSE
Debug.Print TypeOf CRSE Is IStackExchange   ' True
Debug.Print TypeOf CRSE Is StackOverflow    ' False
Debug.Print TypeOf CRSE Is CodeReviewSE     ' True

So, if I know what interface to cast my objects to, I can verify they implement that specific interface. But VBA won't allow me to do things like TypeOf SO Is TypeOf CRSE or Debug.Print TypeOf SO. And TypeName() is not helpful when it comes to interfaces.

How can I obtain more information about an object's implemented interfaces without hard-coding the interfaces' names? Solutions involving additional libraries (as long as shipped with Windows >=7) are more than welcome.

I've seen someone mention casting the objects to an IUnknown type, but that only helps in determining whether two object variables internally reference the same object - it does not tell anything about the implemented interfaces.

Inarion
  • 578
  • 3
  • 14
  • 1
    Have you looked at `TLBINF32.DLL` yet? I'm not sure that its CHM Help download is available any more though, so "you snooze you lose." – Bob77 Nov 23 '17 at 16:37
  • 1
    What is the actual problem you're trying to solve? You want to "determine at runtime whether those two objects implement the same interface" but you also want to do it "...without hard-coding the interfaces' names". Those ideas are conflicting. You won't be able to know if your two object implement the same interface without hardcoding what the interface is. – Jan Paolo Go Nov 23 '17 at 16:59
  • @PaoloGo I had a hunch that I might be asking the impossible. :D (As in the end, all classes seem to implement `IUnknown` for example, and possibly several more interfaces.) My problem was that I tried to adopt some code that contains a type-safe dictionary class. This dictonary was complaining when the LogManager tried to add a FileLogger, while it already contained a DebugLogger. As both loggers are only accessed via their common interface I thought it should be possible to detect that interface and allow them into that dictionary together. – Inarion Nov 24 '17 at 09:05
  • @PaoloGo I've since worked around the issue by adding an `IgnoreTypeSafety` flag to the dict class, which is then enabled only in the instance used by the LogManager, as otherwise type safety seems to be useful to have. – Inarion Nov 24 '17 at 09:09
  • @Bob77 I didn't know about `TLBINF32.DLL`. It also is not present on my system (due to the dll being only available in 32bit? Or maybe it was only shipped with old versions of Visual Studio?) From a brief research it doesn't seem clear to me whether the .dll would enable me to get information about types not formally registered (they are only existent in my project, not in a lib file or anything). If it does, that might be worth pursuing a little further. :) – Inarion Nov 24 '17 at 09:15
  • Don't use the [vb6] tag unless you are asking a VB6 question. – Bob77 Nov 24 '17 at 16:43
  • @Bob77 In my understanding my question is equally relevant to VBA and VB6. (I assumed an answer to my question would be applicable in both environments.) If this is not the case, please let me know - I'll then remove the VB6 label. – Inarion Nov 27 '17 at 08:45
  • If you want an MS Office answer ask an MS Office question: don't add irrelevant tags or you'll get answers you can't use. VBA is not VB but a subset used as a macro language. The environments are completely different. – Bob77 Nov 27 '17 at 16:57

0 Answers0