>>It's a whole new ballgame now with VFP on its own, huh?
>>
>>What are the odds you see on some of the following:
>>
>>OO report writer
>>Fixed View designer
>>OO Menus
>>
>Jay,

>I won't attempt to address these in order or comment, much, on the possibility of their being implemented. Rather, I'll throw out some of my thoughts, in general, on the subjects.

>OOP Reports

>Probably not very high. Due to backward compatibility issues, I'd say that this is pretty low. You might see some things done with Crystal Reports, but in regards to the Report Designer, not much.

>Here's a thought, however, that might prove a bit more likely. A report object to wrap a report. Through this object, we might be able to control, for example, the Print Preview toolbar, or be able to reference custom properties via something like: This.Parent.Property.

>View Designer

>Are there problems with the current one? Yep, but fortunately (or unfortunately, depending on your POV), they're not ones that I encounter because of the nature of my work. There are workarounds, such as Erik Moore's eView.

>I'm reminded of the early days of VB, where they archictecture allowed for the add-ons that became ActiveX controls. In this instance, rather than addressing that, I think it would be much more beneficial to give us a visual DataEnvirnoment object to manipulate. Of course, this is prejudiced by my own work, where something like this would be a great help. As I see it, right now, the data is a function of the form/report and, IMHO, that's backward.

>OOP Menus

>Everytime someone mentions this subject, I usually pop in and say, "...but menus aren't objects in VC++, so I don't think it's very likely that you'll see them in VFP". There's really more to it than that.

>Menus are very often application specific, and as such, there's little to be gained over the current methodology except to say, "Well, they're OOP". Good design can make what's currently available as re-usable as they would be if object oriented.

>Frankly, what may be one of the most overlooked/under utilized features of the current menu system is that it's LIFO stack based. Being an old bit-head (assembly language programmer), I can appreciate and utilize that to give me what I need.

>JMO,
>George

George --

well considered, as always %).

Menus
I haven't "got" the stir about OO menus either. I can accomplish anything with them at runtime that I need to. And, YAG wrote an OO layer to them some time ago, so that can be used, if really needed. But, I just haven't found that it really added anything, except, perhaps some consistency which is rarely noticed.

View Designer
As for the view designer, I do think that it is a significant barrier to developers to use views. Views are so powerful, it's unfortunate that we have such a weak "Weakest Link" in the implementation. There certainly are workarounds, but they tend to be kludgy and the potential for introducing errors is always there when working with multiple tools.

I'd like to enhance the VD (hmmmm) with the SQL parser, eView, and Stonefield Database toolkit. The parts are there...

As you know, YAG's foundation separated data environments from forms from the very beginning. It's progeny have maintained that, to good effect. They had to be hand-coded, though. Until Kevin McNeish released his own capability which allows the visual modification of non-visual classes -- that was about a year and a half ago. So, that exists also...

Reports
Where do we begin with reports?

I like your suggestion about an "object wrapper" for the report engine. I see the issue of object orientation for reports more like the HTML DOM than actually subclassing reports. At runtime, it would be nice to have access to the document or report through an object model for modification of properties, etc.

Enhancements to the basic reporting capabilities -- multiple detail lines.

Output -- can we get beyond printing directly to a printer? Here's a thought. How about opening up the "black box" of the report engine. Provide hooks which would allow developers to read data output data, positioning values, and let us develop our own interfaces to new output formats? I'm working on a project where the developer preceding me basically recreated the report engine in Fox code so that we could generate output to other formats. We have the luxury of investing in that, but few development groups do. I have the pleasure of implementing the output formats %). And, a tip just between you and me -- I'm writing to the Office HTML format of Word and Excel. That format, with some XML and CSS, is about as rich as the native Word format. This writes to both to a browser and Word at the same time, and without the overhead of automation.

You know, none of this is new. In some ways, it seems kind of silly to raise it again, as it's been a concern for so many years, and we've heard for so long that MS would do nothing about these issues.

In no way would I want them to be resolved at the expense of other improvements to VFP integrating into the OS, or contemporary internet development.

And yet, I consider them significant barriers to folks adopting VFP as a development environment. If MS is serious about making VFP a saleable product on its own, I would hope it would address these "ease of use" issues. And, perhaps it can address those by adopting some mechanisms which avoid "reinventing the wheel."

Enjoy!

Jay