>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.

>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.

>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

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"