>Do I wish more ActiveX controls worked in VFP?? You bet. It would be nice.
>I still place the blame on lazy developers. Do you deliver code to one of your >clients that doesn't quite work right and then say "90% of my other clients >like it this way, so you have to take it"? I think not. One of the ways we can >make VFP more visible is to talk with the control vendors and hopefully >educate them regarding VFP.

No, but I have had code that does not work in 100% of installations. Whether it be an unusual configuration - either network or workstation - I have had anomolies at isolated locations at times. Depending on what the nature of things are - it may or may not be a priority of mine to fix - especially if it is within the means of the users to fix. I suspect many ActiveX control vendors feel this way.



>>Over the last few weeks I've spoken to quite a few Microsoft employees about >VFP. My statement to them has basically been "I think VFP is one of >Microsoft's best kept secrets." Everyone of them has agreed with me. (Which >shows me that the VFP marketing team is doing its job.) If we can go to other >vendors and get them to see this, things will be much better for us.

I think many MS employees feel this way - at least off the record<g>. The bottom line here is if a vendor feels a very small number of installs are VFP - they may be hessitant about spending $'s addressing VFP specific issues. Rahter, they may suggest workarounds. Ultimately, it becomes a business decision in that"If it works in products like VB/Delphia/PB, we have done our job.".


>One more note I'd like to make here. I'm not a VFP "snob". I fully believe in >using the best tool for the job. If that tool is VB, Delphi, or even (gasp) >Access, that's fine. I enjoy threads like this and am just trying to add to >the discussion.

You are an open minded guy - and one that I enjoy discussing this issues with. Forums like this - where different points of view can be discussed- are wonderful.