Hi Mark,

>>I am always surprised when I read statements like the above - I wonder why it is that many people are so quick to make up Micorsoft's excuses for them???
>
>Depends on your perspective, Jim. I'm simply stating what I believe to be the truth. I think it's rather offensive to say I'm "making up" anything.
>
What I was *trying* to say is that countless people rush to the defense of MS with excuses of various sorts, *none* of which have ever been officially uttered by MS. If we (that means ALL of us who are interested in perpetuating VFP and growing its capabilities) simply stayed silent on such issues so that MS would have to defend itself, then we just might get to the bottom of things. As it stands now, MS needs say *NOTHING* becuase so many are saying whatever in their stead.
Yet another example of an 'excuse' is the allegation that the absence of a dBase "standard" was FP/VFP's demise. In actual fact Fox Software was 're-writing the standard as they went' and I think we can all agree that it was better for it and thus the way to go. Suddenly the absence of a standard is what 'killed' VFP! We can't have it both ways, now, can we???


>>I believe that it is strongly arguable that MS has been solely responsible for the demise of the FP/VFP developer population, and this really has little or nothing to do with promotion.
>>It has much to do, though, with product quality and product content and product direction.
>
>The quality and content are sufficient for me to use it for database applications, and apparently for you, too, right?
>
Yes, for the moment, but likely not if things continue as they have for the last coupla years! "Integration" into VS which is not integration at all, but rather a "presence". A presence which goes totally unnoticed by the vast majority of trade mags and publications.
For the record, the last coupla years have seen things like:
1) Support for ActiveX is allgeged, but in fact it is lucky support for some ActiveX. The VFP team supposedly tried to tell us that the problem was that most of the non-functioning ActiveX controls played too "loose" with the spec, while VFP was rigid in its enforcement. Obviously a cover story, it didn't wash. Now we *may* have learnd that one of the problems is that VFP cannot support ActiveX which employ 'containership'. I'm betting there are other problems too.
2) Support for Automation (formerly OLE Automation). With VFP 5 it was extremely limited, not being practical as a server to many clients (at least stand-alone) and even with VFP 6 and the employment of MTS, still highly impractical!
3) Continuation of the FP/WIN problem that VFP 'objects' were really screen paints (if that is the correct term) and all of the problems (integrating VFP apps with other developer or end-user tools) that that brings to us.
4) Extremely poor documentation (which, by the way, continues in spades with VFP6!@#@) which can easily be confirmed by reviewing the MS knowledgebase and seeing (a) how often 'working as designed' is offered as the resolution (if the design was adequately documented we could figure that out for ourselves) and (b) how often an alledged capability is shown to be possible *but* in an extremely limited and usually not too useful manner! (c) How the Programmer's Guide has changed for VFP 6. In a word, it really hasn't - there were perhaps 50 (probably less) pages added at the end to relate some details of the new functionality (like ASSIGN/ACCESS, Active Documents, Project Manager Objectifying and Strict Date facility). Done more properly, these things should have logically been *INTEGRATED* into the existing documentation. (d) The Help content - existing stuff has hardly been improved, For instance, virtually all of the 'older' commands (like FLUSH and SET REFRESH and LOCK/RLOCK etc. *still* do not document their impact when BUFFERING is employed, yet they read as if they would be applicable to buffered situations.
5) Failure to listen to the developers (at large) who use the product when delivering upgrades. At VFP 6 delivery I compared the UT "wish list" (which supposedly was to be read regularly by the VFP team) and could not find 3 out of more than 60 items which were delivered in VFP 6! And this is just one source of such communication!
6) Present "focus" on middle tier, which adds up to an excellent chance that:
a) UI objects enhancements will never happen;
b) Objectification of Menu and REPORT functionality will never happen;
c) VFP's super-fast engine will stagnate as-is;
d) VFP's SQL capabilities will stagnate;
e) VFP's database/table capabilities will never be updated with needed capabilities;
f) VFP's capability to intelligently communicate with other active VFPs on a network will never come to pass.

>>Is it only me, or might you also be bothered by the (quite) recent allegations that MS is promoting VJ++ as a mid-tier component??? If there is any truth to this at all, what does that portend for VFP???
>
>It sounds silly to me, but frankly, I haven't been following that thread.
>
>>Above you state, and quite correctly in my humble opinion, that "most developers only use one" (language), though you personally use more than one.
>>I find myself at this very moment doing what I did my very best to avoid - learn VB 6.0! This is extremely troublesome to me, for the time it takes to the brain-power it takes to the brain cells it occupies to the learning curve before I can be proficient at the language.
>
>I know what you mean. I've tried learning it myself, but I just have to have inheritance. It's part of my very being. :)
>
>>It is absolutely WRONG of MS to expect that people should learn more than one language to do a reasonable job at any given moment, and I put it that way because I know and have used at least 5 languages myself, but never at the same time
>
>I don't think they're doing that, are they?
>
Here, again, the folks here who are always writing MS' excuses for them, are always telling me 'get used to it Jim, its a component world' or 'you must use the right tool for the right job, and if you expect to survive with VFP alone then you are a dinosaur' and other gems not worth repeating here.

>>I have never, by the way, seen MS state in any *serious* way that VFP is the best database application language, and they certainly have demonstrated that they don't really believe such.
>
>There was a statement (not even by Robert, if memory serves) just before I left the VFP community about a year ago that said this explicitly: VFP is the best tool for database applications.

WOW! You saw one statement, over a year ago! What have you seen in CONCRETE terms, to have that statement backed up??? A move to the "middle tier", which NEGATES all VFP speed at data access. Where does that suport that VFP is the best tool for for database??? And by the way, the *VAST* majority of business applications *DO* involve database access and usage. In fact I would personally estimate over 95% of business applications need a database associated with them!

Regards,

JimN