>
>If it draws enough cash, you've probably struck gold :). I was just wandering if having a custom object with some properties could do the job (with equal syntax - instead of writing cursoralias.field we'd write object.property) just the same. This object could reside contained in the application object, and thus be used for passing parameters to the report. The only advantage to this is that you can instantiate this object early enough and initialize it (mostly) at app start; I know what I'd use it for - to keep the user company name, address, phone and whatever constitute a standard header. Of course, ability to add properties at runtime would be an advantage to this, thus avoiding the need to define them all in object's class definition, but still would be a bit easier than creating a specific cursor for the report. (Above all, I'd love to have a Custom Report Header Class, instantiate it once in the oApp.init and just copy it to each report... but that's for the Wishing Well List.(
>
>The pattern may be called zig-zagged or polka-dotted, I don't mind :)

I like your approach and feel it quite appropriate for a report header. Now, when speaking of parameters, I can't tell in advance how much of them we'll have to pass to the view, and I don't know their name either. So for now, I'll stick to my cash drawer pattern...

José