I think VB has made significant strides in string functions - but there are still some things natively in VFP that I would love to see in VB. Also, array functions are a bit limited. I don't think VB has anything like Ascan().

IMHO, the biggest limitation in VB - when compared to VFP - is the containership model. In VB, you start with a usercontrol - much like our container - and drop objects onto the design surface. The user control can have nested user controls as well. The user control in turn can be dropped onto a form. Here is where things get different. In the form, you can only interact with the user control interface. If you need to interact with the contained objects, you need to surface those various parts of those interfaces to the outer container - the user control. Bascially, it behaves just like the Control Class in VFP. How often do you use that class? I suspect not a lot of people do.

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.

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 did'nt think it was possible, but it is.


>What features that are in VFP that are not in VB, for example, inheritance, >robust data and string manipulation functions, native database access, macro >substitution and a more extensible and more easily manipulated
>(programmatically) IDE would you most like to see in VB?
>Do you think changing/extending VB's containership model to be more like VFP's >would be beneficial or do you think it just encourages developers to break >encapsulation more?