>>Object Oriented Reports or Improvement of the Existing Report Writer – VFP strives to include a functional reporting tool.
>>Object Oriented Menus – Why?
>
>In my opinion, these two NEED to be done. Why? Not so George Tasker can get more out of menus, not so Jim Nelson, or myself can get more control in our reports. It should be done for new VFP developers, to get new blood on the product.
>
>If I tried to learn VFP today, I think I would be turned off by how inconsitant the product is, the Menus and Reports are completely different (and acient) compared to the Class and Form designers.
>
>What we should strive for is a completely OO, modern elegant language with constiant and friendly designers. I'm also thinking OO data access (a wrapper with a consistant interface to ADO and local data, more or less), but now I'm drifting...

First, I think it was Robert Green who indicated that if a requested feature didn't appear in the product within three versions, it was a pretty good bet that it wouldn't ever. These two requests have been made publicy (that I'm aware of) since at least prior to VFP 5.0. We're now at 7.0, three versions have come and the requests haven't been implemented.

Personally, I'd like to see object based reports. However, it occurs to me that the reason we may not have seen them may be that they can't be implemented without greatly increasing the memory footprint for the resultant applications and/or implemented without breaking existing applications.

I do have one other thought. OO menus and reports are usually application specific and don't lend themselves well to re-use. Indeed, as I've mentioned several times, menus in C++ aren't objects, they're resources. I can see where a single menu pad might be re-usable in several applications, but we can do that now. It doesn't give us anything new except another way to do what we can already. The same thing with reports.