>1.Are OOP menus and OOP reports important to you ?

Menus are not that important, except that it would be nice to have a class of right-click menus with bars[] collection, bar[i].selection method (r/w at runtime, i.e. it could just contain an expression to be evaluated or a name of procedure to be run), barcount property, and the ability to add/remove bars on the fly. That's something I'd surely find good use of. Thinking it over, I may be able to write a class to do it.

OOP reports would be much more important, because the maintenance could be largely eased - the reports which involve just different grouping, or are verbose/concise versions of the base report, need not be all rewritten once the base report has to be rewritten. Also, having a report class would make programmatical definition of reports much easier without much need for messing with all the fields in the .frx file. Defining classes for each of the bands would also ease the maintenance (and spawning of a new report as well). Most of these things can be done by copying the report and just taking care of the differences, but then just deleting one column and taking care of the alignment of the remaining columns is a nightmare; doing it on five almost identical reports is much worse.

Ability to create report textbox class would also be good - would take care of font, size, inputmask etc.

What are we doing here? Brainstorming or just dreaming?