>>I'm thinking now that I'll read these properties in from a second table and stick them on to the instantiated reports menu form class. (Is that anything like Codebook's event/process object?)
>
>Not really. An event or process object performs a task for you and often coordinates one-to-many business objects. So for example you could have a Report Event object that would take the selection from a list of reports and lookup the miscellaneous stuff (title, footer, whatever) and manage running the actual report.

I think I'm getting the picture on this. Thanks.
>
>>The whole idea is that "Department of Pediatrics" may need to be replaced in all of the reports by some other hospital department at some point in the future, so if all of this stuff is in a table it's easy to "sell" the app to other customers and instantly customize it for them.
>
>I agree & using a table like this is common fox tricks. To make it really portable/sellable... give that a table a UI so that you users do the customization themselves & save your group the hassles of customization for each customer.

Round Tuits never seem to be available! Easy enough to add in later when we get to that point.
>
>>This is my first effort at designing a complete application, and my first effort in VFP. I don't want something that a year from now I'll wish I had time to re-write!
>
>If that's the case then I suggest you rethink all the stuff your loading into goApp. IMHO, a heavy goApp object is a telltale sign of a rookie app. And the only time this is a purely aesthetic issue like Larry commented is when:
>- your app will never face scaleability concerns
>- your app provides a singular purpose/function
>- the requirements of your app arent likely to change over it's life

Actually, it might be in this category. Still, it's worthwhile to know the principle and understand why I should apply it or not apply it to my app.
>
>A heavy goApp object will commonly become a technical concern in the following situations:
>
>- your app serves more than one big purpose, and suddenly your told you need to expand it's user base to include additional departments in the organization but the new users can only have access to one specific feature an no access whatsoever the other unrelated purposes the app provides. So either your lucky and security abilities already built in that just need setup for new users; OR you retro fit a means of security onto the app (never a fun task); OR you simply copy the project and split out the one function new users need and roll a new version. Now matter which choice you go with, all those global values in a heavy goApp is going to be a noose around your neck and cause more reworking of code than if the app is originally implemented with all it's responsibilities nicely encapsulated by task.
>
>- your lan-based or 2-tier app suddenly needs limited features available in scaled down browser-baed interface. Ideally you can scarf your existing business objects to save some dev time, but if all those business objects depend on goApp values... and now you have no goApp type crutch to lean on... can we say "lots of rewrites"

Good point. Still, at this point the need is so great to produce something functional by July 1 when the fiscal year changes (the simplest time to transition to a new app). The app itself is simple in concept: import 6 kinds of data, crunch it, and produce about 6 financial statement reports. Right now it's done by spreadsheet manipulation, with a lot of user judgments because the data is pretty dirty. The hardest part will be programming to allow corrections for the most common types of dirty data. The other thing that concerns me is that the accountant will not like it because she will no longer be able to fudge numbers. It kind of makes me a fascist with a PR problem.

I'm insisting on using VFP rather than FPW because I don't believe in doing new development in old technology, so I'm kind of stretched on my abilities. (They get what they pay for!)

Well, I'm off to digest http://fox.wikis.com/wc.dll?wiki~DesignPatterns, though I'm guessing that I WILL end up with a rookie app, since I'll never have time to digest all of that before I need to do the work!

Thanks for your wonderful comments.