Inheritance In Vb Classic

VisualBasic 1 through 6 (aka VbClassic) directly support interface-inheritance (subtyping) but not implementation-inheritance (subclassing). If you want to do ImplementationInheritance in VisualBasic, see the VbClassicImplementationInheritance page, for tips and techniques.

VisualBasic (1-6) directly supports interface-inheritance (subtyping)

Classes can have several interfaces. If a class implements an interface it just has an interface more. It is not possible to create a new interface which inherits from another one. It is not possible to create subtypes. Objects can have several types, but there is no hierarchical relation between these types. (Except very few special cases, like: instances of any user-defined form (not UserForm?) are also of type Form.) If you want to use an instance of a class which implements several interfaces, then you have to decide which of these interfaces you want to use. VB does not create a new interface which combines the features of the different implemented interfaces.

It is true - use IDL

IE: You can define COM interfaces that inherit from other interfaces in IDL, and then implement the resulting COM interface in VbClassic.

You can implement any OO design in VB, it's just that it some cases it requires more programmer discipline than with other languages. There are OO designs which can reasonably be implemented with VB5 or VB6. If you want to use a deep inheritance hierarchy then the use of VB (before VB.NET) is very questionable.

I'm not sure I understand the statement "And many VB programmers need Inheritance". Why do they need it? As an avid VB programmer, I always seem to find reasonable solutions using VB Containment And Delegation, Events (COM Connection Points), Modules, or GlobalMultiUse? objects for OAOO. If I really "need" implementation inheritance for "virtual" methods, I'll use C++. VB is COM. COM does not support implementation inheritance. Even in C++, COM Aggregation is the best you can do if the base class lives in another COM server.

Another issue with some of these "base class containing the derived class" approaches is COM circular references (VB memory leaks). Two VB COM objects should not hold references to each other. The Outer object will always have a reference count of 2 (one for client and one for Inner) and the Inner has a count of 1. If the client releases the Outer (set pOuter = Nothing), its reference count is now only 1 and the Inner's is still 1. Neither will be destroyed and the "pointer" is lost! In C++, you can manipulate IUnknown directly, but not in VB. McKinney? (HardCoreVB) describes a way to circumvent IUnknown::AddRef, but its ugly, error prone, and highly unstable. Why bother?

There's a way round this (http://www.vb-faq.com/Articles/Hughson/proxyobjects.asp) that lets you do it without any scary API stuff.

If you "need" implementation inheritance, why use VB? C++, Delphi, VFP, and J++ all provide it and support COM as well. If you're using VB, bend with the language [possibly a case of doing the SimplestThing]. Just my ramblings...

-BradTaylor

Use split identity. Circular references are inherent in reference counting. All solutions are to some extent a hack.