> If the containership model in VB was a little more flexible, I think you would start seeing more VFP folks giving VB a serious look.

It is one of the main things that's kept me from using it much.

> The inheritance issue. Well, the time I spent over on DevX gave a good perspective on that whole issue. Yes, the way things in VFP are done with regard to inheritance is nice. But in all fairness to Karl, Zane, Kathleen, Phil, and the rest of the folks on DevX, they made a compelling argument for the way things are done in VB.

> The book I am reading and going through now - Professional VB 5 Business Objects - does a great job of illustrating how OO design principles can be implemented in VB. I didn't think it was possible, but it is.

You can apply a lot of the principles in Fox 2.x as well, but that really doesn't make the product itself OOP now does it? We had "non-visual inheritance" in FoxExpress 2.6. But I agree, OOP is as much a methodology as a feature. By the same token, just because a product has OOP doesn't mean you're using it. From what I've seen, the OOP techniques in VB don't really amount to much other than good procedural programming coupled with the ability to pass objects around and encapsulation thrown in.

I think there are a number of ways to get around the lack of inheritance and in general, VFP developers tend to be overly dependent on it, but the lack of it is still a serious issue IMO. Despite what you can do with delegation, decorators, etc. Visual inheritance is still important to me and I don't like the idea of using techniques that make my visual components look dramatically different at design time vs. runtime in most cases.