>Well, if you buy VFP7, you buy it knowing what features are in it.

A pure statement of fact that I agree with...


<<
Expecting them to give you more features for free after you buy it isn't very realisitic, but fixing the existing features to work as advertised is.
<<

You miss the point. The point is to get people to upgrade. I find it interesting that this discussion is occuring. It can only mean that not as many people are upgrading as was expected to upgrade. Put another way, not enough people are upgrading to warrant making VFP 8 a slam-dunk that it will release. For the record, I think 8 will be a reality.

My points have nothing to do with trying to get something for free. The point has to do with people that still have not upgraded when the first SP comes out. Finally, I would make the argument that something as insignificant as a properly highlighting Grid Row is a feature that should have been in the system 5 years ago.

The carrot and stick approach that is being used simply rubs me the wrong way...


>
If every VFP7 service pak introduced two new features, where would you draw the line saying this isn't 7.x SPx, its 8.0?
<

If a feature is in SP 1, it would be VFP 7 SP 1. When the MT DLL came out, the version was called VFP 6 SP 3. I don't see the issue here....



>How could you make money giving out new feature after new feature for no cost?

You would make money by making the product a more compelling upgrade. If you knew that more people would upgrade if a new feature or two was in the service pack, you would make money. How much do you think a feature like highlighting a grid row would cost??? We are not talking about big bucks here. My suggestions can easily be defended on marketing and economic fronts...


>I understand that giving customers more than they expect is great for the customer, but realistically (and you of all people should know this, John), you can't make money giving this stuff away for free.
>

First, please don't patronize me. Ken did it in his response, and I did not appreaciate it there. Second, as far as giving "stuff" away for free, I have already addressed that point...


>
Compelling features like the COM enhancements, Intellisense, XML functions, Web Service Publisher, TEXT TO, Intellisense, stability as Ken mentioned? Oh, did I say INtellisense? 7.0 defintially has (IMO, more than) its share of compelling features.
>

It is clear you don't understand the make-up of the VFP market. As far as COM and XML is concerned, my guess is that no more than 10% of the VFP development community uses those features. Web services? Developers using VFP are most likely using Web Connect. My guess is that less than 10% of all VFP developers are using VFP in their web apps. Rick has already taken care of this part of the space, and very well. If I had the choice between using "web services" and WebConnect, I would choose the latter. IntelliSense is indeed a good reason to upgrade, but for the seasoned developer, it is way down the list. It is of far more value to a newbie/intermediate developer. Still, I will concede this one. Text To..., I will concede this as well.

Out of the 6 features you enumerate above, 2 (30%) of the features you cite will be of use to the AVERAGE VFP Developer. Intrestingly enough, you did not mention DB events. While I do not use VFP data or the DBC, I would concede that too is a feature that an average developer would use. However, would a developer retrofit an existing app? I don't think so. Therefore, it is likely that feature would only be used in new development. That requires that one take account of just how many new VFP apps are being built today as opposed to enhancing existing apps with new features. Yes, it is possible that a developer might outfit an existing DB with code to operate when the events fire. Still, I find this highly unlikely since the DB sits at the core of the app...


>
I understand exactly what you're saying here, But we've been told that problems and ommisions can be fixed. In order for that to happen they need to be reported in the first place. Thats why you're seeing these issues, or "complaints", being brought up.
<

We shall see.... Of course, to be a problem, one would have to conclude the omission makes a difference. I contend that only those who currently use VFP will upgrade/use the product. When it comes to new development, you can bet that MS wants it developed in .Net first. If the people involved are not inclined to do that, MS would suggest a whole slew of options before getting to VFP.

Don't get me wrong, I think VFP is a great tool. I think it addresses classes of applications that .Net was not designed for. The fact is, MS is trying to be an enterprise company, not a line of business company. Products like VB and VFP, out of the box, are not enterprise development tools. In order to develop enterprise apps, you need the addition of developers who are at an expert level. The idea behind .Net is to balance out the equation. i.e., reduce the level of developer you need by improving the tool. Will it work? I don't know. Time will tell... I do know this...if one considers himself a MS developer, one better become acquainted with the enterprise market; since that is the strategic focus of the company.