>Hi,
>
>I've been following the talk on this thread on and off lately to see what options people are considering after vfp. We are a single app shop that has a long-standing app with custom hooks into a number of COM-based services and other custom technologies. vfp will be around for a long time, but as MS backs away from VFP, VB, and now plans to back away from COM, ODBC, OLEDB, the newer (in-demand) interface technologies needed to connect to the latest (in-demand) services will become less and less vfp options.
>
>However, has anyone looked at the UT Mag article on the extender/compiler being built to integrate vfp with .net? If it became a reality, it could truly extend vfp another 10 years. The big question is whether MS may be too greedy to let that happen. Notwithstanding some remarks about people at MS losing sleep over us losing our language, it seems to me that MS has deliberately worked at patiently and "compassionately" killing vfp for a long time. After all, there is eula agains vfp code running on another os. Is there such a stipulation on C code? It seems to me that MS has made every move possible over the years to limit vfp sales and cut vfp staff while sending messages that they "care." I am not speaking specifically of the vfp unit, itself, necessarily, but the next level up.

Yes, I have read the article this afternoon, and it will get my attention. Good that you bring this issue to our attention here. Hopefully others will respond also.