>
>Not when it comes to full compliance with ActiveX controls. And, not when it comes to making use of ActiveX Data Binding and ADO.
>
>>>VFP is superior to VB as an object-oriented development tool where business rules can be classed and ActiveX controls can be subclassed or wrappered.
>
>Be careful here as you are mixing and matching things. It is important to disguingish things between business objects and the UI. When it comes to OOP - don't even bother to include VB - at least not yet<g>. VB is not OO - it is object based. Until it becomes OO - and more specifically - adopts inheritiance
>- it is an irrelevant comparsion.
>
>When you mention wrapping ActiveX controls - you are talking UI - which may be or may not be an advantage. For example, if my UI is sluggish - I could care less about the OOP abilities to subclass ActiveX controls. Also, if I need an ActiveX control - and it bombs out in VFP - but works fine in VB - I might be making the change anyway<g>. Hey - we are'nt even talking about C/S here are we??<g>.
>
>


I don't totally agree with you here. One of the big problems that VFP has with ActiveX controls is not VFPs fault. It is really the fault of the ActiveX developers. VFP is much more strict at enforcing ActiveX standards than VB. When the control developer doesn't follow the standards, VFP chokes. That's not VFPs fault.