Thanks John,

I thought I was suffering from some disease, that caused me to not read correctly what I had just wrote.

Claude, let me try to say another way. I never said that I knew for a fact that features will be introduced in .Net, just the possibility. However, a perfect example is "Reporting Services" that were added to SQL Server. To fully make use of them you develop using a control that gets added to a .Net form. In the old days it probably would have been an ActiveX control. Do you not agree that many features made their way into VFP thru ActiveX? Were those ActiveX controls developed because of VFP. I think not. Typically they were developed for VB, and it just so happened that they would run in VFP also.

Do you not think that the 3rd party tools market for VFP is going to shrink significantly if not dry up completely. What motivation is their for tools developers to aim towards a market the size of VFP?

>LMFAO... Where did you come up with .Net is the end all and be all for MS developers? You, Terry and John need to learn to read. Perry never said that. He said that cursors are not a big whoop for people not programming in fox. That's it. I don't think implied anything else.
>
>
>
>>Isn't it possible you're only seeing what you want to see? Aren't you assuming an awful lot by thinking .NET is the end all and be all for MS developers? I myself hate following the masses into some predetermined marketing route from Microsoft. VFP can be extremely flexible and I like proving people wrong about it. It's not perfect but what really is??
>>
>>>John,
>>>
>>>Your post is a poster-boy for the problem here. Much like in politics where people obviously only here what they want to hear. Typically, whatever supports what they already believe.
>>>
>>>I have had plenty of discussions with my VB/.Net friends and Java co-workers. Guess What??????? Cursors are absolutely, positively, matter-of-factly No Big Whoop to them.
>>>
>>>Everyone here continuously harps on the believe that MS killed Foxpro. I just don't think they are seeing reality. I just don't believe that there are that many places that switched from VFP because MS told them too. Lots of these companies wanted to switch to get other benefits.
>>>
>>>Also, I think the number of people who were getting ready to build a new product from scratch and potentially using VFP began a substantial shrink within the last 10 years.
>>>
>>>From a software developer point-of-view, such as where you are coming from, by using VFP instead of more modern tools, I would worry that features would be introduced in the more modern tool that would never make an appearence in VFP. If your competition makes use of these tools, you could be behind the 8ball.
>>>
>>>>Rick,
>>>>
>>>>What makes a FP cursor special is its automatic memory/disk spanning. Whether people like it or not,
>>>>
>>>>

use mylookup order myorder

>>>>
>>>>offers a smorgasbord of options for very little risk or cost. It isn't the VFP syntax that delivers the benefit but the automatic memory/disk spanning. For a start, it allows efficient 500,000 row static lookups at app end or middle tier with no network cycles or SQL load. While this is well understood in VFP, I agree there are legions of developers out there for whom such local data stores would be seen as unpredictable local memory hogs, best avoided in favor of Server-side processing. Well, in VFP you can go either way. I don't want to lose that.
>>>>
>>>>i see that some of the Python-spawned languages are starting to offer memory/disk spanning. That's smart. Hopefully that is what MSFT means by a "local data engine" as well.
>>>>
>>>>To be clear: this isn't about "VFP is best". It is about improvements to MSFT's designated successor language- improvements that may well be enjoyed by other developers who may have seen a role for a local repository but decided it must be bad design. To me it feels a bit like the belief that diesel engines are noisy, smelly things for trucks, not luxury passenger vehicles. It doesn't have to be that way.
>>>>
>>>>Regards
>>>>
>>>>j.R