>>>>As far as authorship, I don't know. For sure it ships with the product, so as such is part of the product IMO.
>>>
>>>I see that quite differently. The core VFP functionality that goes into the products we make is more important, to me and apparently to the VFP team than the "productivity enhancing" add-ons. Doesn't matter if they shipped with VFP or not. Do you take code from the help and use it in production?
>>>
>>>I don't rely to heavily on the add-ons and I never, ever use them for anything other than as samples or when they really help my productivity. The client never sees them.
>>>
>>
>>Mike, I am completely puzzled by what you say, and I don't say that in an argumentative way at all. I do not understand the distinction you are making. As a developer I paid my money for VFP and I expect Code References to work as well as the rest of it. It's not a third party product. It's part of VFP. I don't ship MODIFY STRUCTURE or MODIFY FORM, either, but I expect them to work.
>
>Your expectations differ from my observations of the state of affairs. ;) Here's an example. There's a nifty little calendar function that comes with VFP. ACTIVATE WINDOW CALENDAR. It is far from useful for a professional application. It is part of VFP, but it doesn't work as I'd expect it to. The grid was not rushmore optimizable until VFP9. It should have been, but it wasn't.
>
>Modify structure and modify form are not quite the same as things like the code references tool or the ffc, imo. They're far more "core" functionality, if you take my meaning.


OK, I get your meaning, but I still consider Code References to be a FoxPro developer tool, not some little non-VFP utility off to the side. We can agree to disagree. I am already fighting off the jihadists and can't fight simultaneous wars on two fronts ;-)