An OOP report can be easily manipulated in runtime. Right now, if you want to control the report in some way during runtime, you have to "hack the report" i.e. open it as a table and directly insert values. I have never done this. Since the structure of reports (and other vfp objects that are really tables) isn't documented, it always seemed like a black art to me, requiring trial and error, and the help of your UT buddies.

I have a set of manhour reports that have graphs in them. Because of the limitations of graph, I made two different reports for different subsets of the data. Then I needed versions for hours and dollars, so that made four reports. Then I needed versions with and without budget lines, so I then had eight reports. Now I've been asked to make versions in color and B&W, which would make 16. So I've decided to be smart and set some of these parameters programmatically. That will be much easier to do ... because these reports are in Access.

I don't believe it should take M$ that much effort to do for VFP what they have already done for Access97. VFP reports are an embarrassment, for that reason alone. Here we are always saying that VFP is the real OOP environment, but it has this gaping hole in its object model. I don't really know if this issue is the most important one in VFP, but M$ should address it because what we have now is just the wrong way to do things.

Now, if I could just figure out how to get an object reference to the graph object in my Access reports.... Sorry, just fishing. If anyone has advice for me on that matter, I suppose they should click the little envelope and use my private e-mail, since it's an Access problem.

>I have no idea what OOP reports or menus would do, since I've never used them. I have used some other report writers, but they're data handling is so slow compared to FoxPro that I generally do all the data massaging in FP and let the report writer just handle the display of the data.
>
>For that reason, I think that the report writer is just fine.
>
>I do wish that the menus didn't run off of compiled code. I didn't realize how much time I was saving by not being required to regenerate and recompile a form until I made a change to my menu the other day and couldn't get it to show up on the screen. (Oh, you have to regenerate it and recompile!!! <g>)
>
>Also, the commands to create and run a menu are some of the most arcane in the language. Why can't I just design the menu and run it just like reports, forms, databases, etc.
>
>So, I think that, with some minor changes, menus could be made much better and reports can stay like they are.
>
>>Hi All,
>> I just wanted to run something by everyone. I as most other people have a list of new features that I want to see in the next versions of VFP. There are two features though that I am not so sure make it to the top of my list like they might for other people here.
>>
>>These two features are OOP Menus and OOP Reports. I am not so sure what the big benefit to these features would be so I wanted to run it by this group.
>>
>>So here are my questions
>>
>>1.Are OOP menus and OOP reports important to you ?
>>
>>2. If you answer yes, WHY ?
>>
>>3. If you answer no, WHY NOT ?
>>
>>
>>All answers are appreciated.
>>
>>
>>Rod