Snippage below...


>I do now where it's appropriate. There are serious flaws IMO with how VFP's COM objects work at the moment; the memory footprint of VFP COM objects is as large as the VFP runtime for a monolithic VFP app. I happen to like the VFP form paradigm, and don't like the VB model of inheritance (aka cut and paste). There are classes of applications where VFP would be the right tool for the whole job if it weren't for the flawed behavior of forms and controls.
>

The flaws I see are the lack of ability to define/raise events -and to respond to other COM events - although this issue has been addressed in thew new VFPCOM DLL. VFP is not a light-weight client by any stretch of the imagination. The new version addresses the scalebility issues with MTS. I for one am not that concerned with the footprint of VFP COM Objects. Its a function of hardware and resources. Put something decent on the server, and things will work out fine.

>My introduction to the problems of VFP and Active Accessibility and thin client environments came well after the initial deployment of several applications; it was disappointing to find how difficult it was to make a seemingly simple set of forms available to the visually handicapped, especially with MS pushing Active Accessibility as a major feature of their environment, as evidenced by their shipping it as a part of Win98. In one case, I went back and used the JAWS API to reinstrunebt the existing VFP app - the client wanted the benefits of many features of VFP not easily made available to a VB app, and they had the budget and time to invest. In another, the client moved the individual who couldn't use the VFP app to another task, because the budget wasn't there to rewrite or reinstrument the app. As an inability to use the application affects the individual's ability to advance in their job, I wouldn't rule out future litigation as a result - but the money to rewrite isn't there.>

Have you presented these issues to the VFP Team??


>The problems of VFP in a thin client environment are well established - I've >ruled out VFP a number of times for precisely this reason.
>
>If we aren't going to make VFP a 'real' Windows product, let's consider scrapping the UI entirely, having MS develop another strong OOP front-end tool to replace it. That makes VFP a competitor with anoth high-profile MS database platform (SQL Server 7), it pretty much smells like the small developer community of VFP developers will die off as MS moves resources that could improve VFP into making other products fill part of the niche. Fix the broken arm by amputating and putting on a different prosthetic just isn't good medicine in my book.
>
>John, why are you so reluctant to admit that there are flaws in VFP's implementation? I'm not saying that VFP should be an end-to-end environment, but that if we want it to fill a niche in the MS multi-tier strategy, they need to get SOME part of the tool right. The UI isn't it, the thread model and COM behavior is flawed, and there is too much missing to make it into a real backend. What does that say to you?


I am not reluctant to admit that VFP has flaws. I think every environment does. You are picking on some very specfic areas - the UI - which I think is an overblown issue. The threading modeling has been addressed. Many of the limitations with COM Events has been addressed. Granted, these new features are not available now - and that is important. But, these issues don't impact me now. As far as a backend goes - I think it does well. Is it on par with SQL Server? In some respects - yes. In most respects - no. Then again, it is like comparing apples and oranges. VFP works great for me. Instead of just going with the flow - and picking on a few areas - I choose to go on my own experience and draw my conclusions from that. I am not saying that is what you are doing - but many fall into that category.

>
>What is your position on this matter? Is VFP's UI perfect, and completely adequate? Is the VFP implementation of COM complete and ideal for deployment at mid-tier as it ships today? Is it the ideal back-end? You've belittled the real complaints of a large segment of the developer community - what is your position on the flaws, or lack of flaws, in VFP as a product today?
>


Belittled is a bit harsh - don't you think? My point is that many folks complain about a lack of features they would not use anyway. For those that need MTS to scale thier apps - yes - there is a big issue there. You three choices:
1. Suck it up with VFP - and wait for a fix
2. Use another tool
3. Use a combination of tools

Are there issues with VFP - of course there is. Check out the folks in the VB community that are complaining. Now those folks are really pissed off. As far as the sentiments being from a large group in the VFP community, I think you may be over-stating that point a bit. As I see it, the VFP community is no different than any other community. There are features we have wanted forever - and have yet to be realized. No tool - including VFP - is perfect.

I'll turn it back on you - with all that you have spelled out here - have you echoed those sentiments to Robert Green? If so, great. If not, may I ask why???