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