>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.

I do, but it isn't reasonable IMO to have the combined overhead of both the full VFP runtime and VB's runtime, and maybe a browser as well, present for simple desktop applications. The problems of multiple instances of the VFP runtime in a server environment for VFP as it ships now are pretty well established - they step on each other, making scalable remote deployment of mid-tier objects a problem if you want to follow the Microsoft-endorsed view of development! I'm not privy to the internal plans of Microsoft, and I'm pleased to hear from the people involved with the upcoming 6.1 release that many problems, including the threading issues and memory footprint are addressed there. But there's no date for when that stuff will be available to the general developer community (including those of us shelling out $2K/year for a Universal Subscription).

This may sound like sour grapes, but I've been waiting for things to work out fine in VFP for a long, long time. A public beta, and a believable delivery schedule, would go a long way to making a believer of me. I am aware that the next (or next two, or next 5) releases won't address all the problems, but a real date when the fixed stuff will be available, and exactly what, as a minimum set of enhancements will be addressed in the upcoming release, would help make some peace.

>
>>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 issues have been presented by myself to Microsoft about a year back through at least one client (Pitney Bowes), through the American Council of the Blind
to the Active Accessibility team at MS, and through Henter Joyce, the developers of the JAWS for Windows product, to several groups at MS. The response has been lackluster at best. Henter Joyce's position has been to put their efforts into supporting Active Accessibility compliant products as recommended by Microsoft, while continuing to supply and support their own API library as best they can (they have far less staff than Microsoft, and frankly, it's easier to get to one of their engineers as a developer working with a JAWS user than it has been to get a response from Microsoft's engineering people to a Priority Response call made as an MSDN subscriber.)
>
>>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.
>

I'm not a carpenter with just a hammer, so not all problems look like nails. I've been using a mix of Microsoft products for quite a while; I still tend to roll wrapper .DLLs in C to make segments of the Win32 API more available to my applications in VFP, rather than relying on complex and convoluted code in VFP to avoid writing a tiny bit of C. It's easier to use the right tool at the right time. It's also easier and desirable to fix flawed tools; the idea of a screwdriver with a clamping tip makes the screwdriver more versatile in many circumstances. A clear statement of what the direction of the language will be, along with clean implementations of improvements in those areas is needed. The statement that VFP6 'fixed' the VFP COM object problem was less than forthcoming; I believe that it will be fixed, and that it's the direction that MS is pursuing, but it's not there now. Don't pee on my head and tell me it's raining.

>>
>>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.

If I thought that VB were the direction that was best pursued for general development, I probably wouldn't be nearly as active here as I have been the past few months. And I think that it's going to take a whole for many VFP developers, who have become accustomed to using VFP as their single development tool, to chage their position. I do believe that MS is driving away a significant core of developers, and that problems in VFP 6 as a deployed product are excessive. Whether the VFP copmmunity benefits from what I consider to be a premature release of a product remains to be seen. Clearly, people who become attracted to VFP based on the press from MS will have to a large extent been disappointed by the promises made but not realized in the VFP 6 release.

>
>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???

No, I haven't corresponded with Robert directly, except here on UT. As to why not - I've been busy finding workarounds to the problems I've encountered and developing applications. While I feel I contribute to the VFP community, my first responsibility is to stay employed, and keep my clients happy. As a result, when I find something, I let others know about it; the first ones I notify are my clients, who keep gasoline in the car and food on the table. I pay Microsoft for their product, and I make my positions known to Microsoft through public forums. Is Microsoft responsible for tracking down and responding to reported problems? I see as many workarounds and fixes published here on UT as I see in Microsoft Knowledge base references.

I seem to get better support from the developer community as repreented here on UT, in most cases provided without compensation to the people who bust their humps to help out, than I see coming out of Microsoft, who we paid for the product. If I have a question about something I can't get to work in the API inside of VFP, I'll go to Vlad, or George, or Bela - they'll get back to me quicker than the support people at Microsoft will! My lifeline for VFP is the developer community (admittedly, many of whom are recognised and to some extent rewarded by MS as MVPs). Maybe I should spend more time submitting bug reports to MS, but then, maybe Microsoft needs to monitor what goes on here a bit more closely to see where people are having problems.