I am reponding to my own posting to give a clear answer to my question in light of what people have said to me in response and what I have found on my own. Much of this is probably common knowledge, but I feel it wraps up my issue.

>My first difficulty is using protected methods and properties. I find myself unable to access these functions and properties from instantiations of the class. Is this correct behavior? Is this reaasonable behavior? I often find myself declaring properties and methods public, even when they should not be.

There is a philosophical question underlying this issue. If I create an instance of a class on a form, should this instance be treated as a subclass in the class hierarchy? In C++ this is not a question, since you can not, for example, override methods without creating a new class. On the other hand, in VFP, we can override a method in the instance of the class. Perhaps this flexibility led the VFP designers to make the choice they made concerning protected members.

If A is a class, the protected method PMETH can be entered in any subclass by typing the line A.PMETH(). This line can not be used in the instantiation of the class on a form, proving that VFP does not consider this another class, despite the possiblity of multiple overridden functions. At the advice of an officemate, I used the scope resolution operator and the line BASECLASS::PMETH() worked fine from the overridden method of the instantiation. This was the solution to my original problem.

In the end, I would have to respectfully disagree with those who felt the VFP protected was limited in usefullness. Actually, it seems to have all the power it should have. Still, the computer scientist in me is curious why the instance can still access protected members but must use a different technique than a subclass would use. Why not allow the line NAME_OF_INSTANCE.PMETH() and leave the scope resolution operator for cases where the issue is scope. The issue here is access, not scope. Since the instance of the class is allowed access, why not exploit this access through the proper operator, which is the member of operator or '.', not '::'.