>Then why not use VB or IE as your UI - coupled with VFP COM Components???
>
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.
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.
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?
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?
>
>>>This is simply not true. Yes, there are controls that do not work well with VFP. However, I would submit that most controls - work fine. Simply put, you can't substantiate what you are saying and concluding here. Sure, there are issues like binding ADO Recordsets - and that is being fixed. However, I would also submit that the ADO is not that big a deal right now....ActiveBar works fine. The MS Agent works fine. VFP 6 fixed issues regarding the TreeView/ListView. Please Garrett, if you are going to make conclusions like this, back them up with facts - not conjecture....
>>>
>>>Also, please tell me how VFP's lack of true Windows Control's affects your day to day development. Specfically, name for me 1 thing you cannot do becuase each control does not have an hWnd Property. Please don't tell me you can't use Visual Test. Yes, it would be easier - but there are workarounds. However, even that issue does not impede development. I have heard of issues with Citrix - but none of these appear to be really substantiated. I have used Citrix with both 2.x and VFP apps. Unless you use Citrix, this is not an issue. So, barring these issues I have brought up - please tell me how the lack of true Windows Control's negatively impacts your day to day development.......
>>>
>>
>>John, from a realistic perspective, VFP's lack of real Windows controls makes use of VFP in environments where Active Accessibility is an issue a BIG problem; I have a number of visually impaired users who rely on Active Accessibility compliant screen readers like JAWS for Windows, and VFP apps, especially those using VFP native controls, are extremely difficult to coordinate with, control from, and even have recognized by the screen reader software. Since VFP controls are viewed as a single bitmap, it makes it nearly impossible for Active Accessibility compliant software to recognize change of focus, especially within complex controls like grids.
>>
>>The lack of real Window controls also makes VFP slow in thin client environments - you've already mentioned one (Citrix); another is Microsoft's own Windows Terminal Server. There's also noticably worse performance with VFP apps that are screen intensive using remote control applications like PCAnyWhere. With the option of using another product that does have real windows controls for front ends in this environment, and VFP in a mid-tier role there are certainly workarounds, but it would be nice at times not having to turn to another tool for UI, especially if you like VFP's approach to form design and implementation.
>>
>>There are significant API calls that require use the hWnd of a control to use them; little things, things like SendMessage() and PostMessage() (completely minor and unimportant, useless things, right?) are good examples. This makes interprocess control of VFP forms and native controls more difficult at best, and impossible in many cases. I'd really like to be able to have a VFP control act on a message sent from another process (or even another thread within VFP when we get real threading.)
>>
>>So there are reasons for wanting VFP controls and forms to behave like other Windows things, and they aren't obscure, demented, minor requirements of a small fringe group. While I realize that redesigning VFP to use native Windows controls and better integrate many currently at-market ActiveX components would probably kill off all other progress in the language and break a ton of stuff, there's still a reasonable desire to see it at some point.
>>
>>For me, there are more important issues, like the thread model and platform stability that I'd like to see addressed first. Recognizing that there's a problem here isn't a criminal offense, though, and I'm sure that other developers, especially those who are really VFP-centric, single language developers, have different priorities than I do. Please don't just dismiss the problem of VFP controls and Windows as trivial and unimportant.
>>
>>
>>>>Because of all the ActiveX controls out there that only work in VB: I was hoping that this would make them operable in VFP. I know there are other issues, like VFP's lack of true windows controls.
