>Hello, George.
>
>>>>Object Oriented Reports or Improvement of the Existing Report Writer – VFP strives to include a functional reporting tool.
><snip>
>>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.
>
>I almost had lost any hope about OOP menus, after reading the infamous "Get a hint" words from Robert Green. But I was reading the transcript of a spanish chat that Ken and Ricardo Wenger held a couple of weeks ago in PortalFox, and when asked about OO reports by a lot of folks (as usual), Ricardo said "we are thinking about a solution for that..."
>
>Wow! First time that somebody SO close says that.
>
>About your arguments about the possible implementation, I have two comments:
>
>I use a Report Class from Doug Hennig that masks the FRX file from time to time, to solve the standard header and other related problems. Also, I started using it to build reports on the fly.
>
>I think the class is a little cumbersome to use, but this is a VFP fault, not Doug's (who made a realy impressive work).
>
>And the FRX file structure is (somehow) simmilar to the SCX, so I don't think that it would be so hard to retrofit. Indeed, they most probably can keep supporting the old (current) format even changing the report designer.
>
>Just imagine setting objetc properties on the Properties Windows instead of doing so in the many (different) dialogs as we do today. And of course, having some additional properties.
>
>Just my two argentine cents (=0.02 US dollars) :)

Martin,

Interesting information about Ken and Ricardo. I've always thought, however, that the request of OO menus and reports have to be considered separately in terms of what they involve. In some ways they're similiar, in others, very different.

Menus

As of now, the compiler takes the metadata found in the MNX table and generates code for the menu via Genmenu.prg. It then tokenizes the code.

In order to implement this, at least two, and probably three areas of the base internal code would have to be changed by making menu objects. First, the compiler would have to be changed to recognize a different format for the metadata. Second, how the menu is to be invoked (currently DO Mymenu.mpr) would change since the code would now more than likely not use Genmenu. Third, the interface for designing menus would also have to change.

These are a lot of changes to the existing, stable, code base.

There's one point that I've made several times: Menus in VC++ aren't objects, they're resources.

Reports

As of now, VFP uses the metadata stored in the FRX table when required (no program generation or tokenizing) to generate its reports.

I mentioned to Gerry Schmitz in another part of this thread that the idea of a change to the syntax connected with generating the report might be feasible. This would involve add the AS classname FROM classlibrary clause to the CREATE REPORT command. This would allow the creation of a "template" report class from which other reports (as FRX files) could be derivived.

This approach is less involved, since it does not require many changes to the current report generating engine, which is quite complex. There may be some, depending on the implementation. What would need to be changed or implemented would be a way of deriviving the report and linking it back to the parent. There are other issues, but to me, this would probably seem to be the most significant.

Further, the modifications to the existing interface for report designing would not necessarily (from my understanding) as great as they would be for menus.

Lastly, I may be incorrect about some of my assumptions here regarding the feasibilty and future implementation. Wouldn't be the first nor last time.:-)