>I am wondering: What are you saying "Nope" to specifically?

To everything. :) Basically, you're speaking about composition, not inheritance. More precise, the inheritance for a composite class, which is different than a class with multiple parents.

>Are you saying that in the example I gave, TestClass class does NOT inherit properties from two classes? It does, right?

No, it doesn't.

Let's say that A is based on a container and contains two objects of classes B and C. Our TestClass is derived from A.

Class B has a BProperty and a BMethod.
Class C has a CProperty and a CMethod.
But class A doesn't have any of the above PEMS. Class TestClass derives from A and it also doesn't have any of these PEMS.

If TestClass would inherit from B and C (as it is required by multiple inheritance), you could write
oTestClass.BMethod()
oTestClass.CProperty = 4
but this is not legal in VFP.

It's true that TestClass inherits the B and C objects (this is still single inheritance) as it does with any other PEM of class A (contained objects can be seen as object reference properties).

So, TestClass inherits only from A, not from B and C.

The fact that you can change the code for the methods of the contained B and C directly in the class designer is only a shortcut in VFP. If you want to put it into strict OOP, this would be translated to:
-B1 derived from B
-C1 derived from C
-TestClass contains a B1 and a C1.
Something similar happens if you change the same methods directly in A.

But, as I said, this is not pure OOP (because, when a method is overridden, the class is no longer the same, so, it's a derived class in fact.) But this burden is hidden in VFP and makes many tasks simplier. It also accounts for the many and difficult problems one can run into when container classes are derived.

In other words:
Inheritance is a "is a" relation, while composition is a "has a" relation. In this case, TestClass "has a" B and "has a" C, but TestClass "is not a" B or C.

>Also, in this example, it is possible to override any method form either parent class.

See above. The overidden methods are not from parent classes, but from contained objects.

>What does happen when you have parent's with the same properties and methods and they conflict?

I assume that, depending on the language, there are rules that clarify such conflicts. The only language I know that supports multiple inheritance is C++. Any rule that eliminates confusion is good.

>I am still not convinced that some of the uses of multiple inheritance can't be simulated in VFP.

The uses can be simulated. But only simulated. For example, in the above example, the programmer can define the BMethod, BProperty, CMethod and CProperty for the class A. The new methods would call their correspondents from B and C, while the properties can be inherited using accessor functions (yet another great use of accessors!). But this code must be written and it may imply A LOT of code and A LOT of maintenance.

Multiple inheritance would make it by default with no code necessary.

Vlad