Keven,

What relationship or technique should I use for having a main app with the MM classes and sub apps with only the specific application classes? In other words please comment or correct this scenario:
A main app leads off with all MM base classes in it, prompts the user for a logon and then presents it's main menu.
When the user selects an application say "General Ledger", is the main app just running the entire General Ledger compiled exe thus creating a new applcation object, requiring I set up a custom procedure in the new oApp object to accept a parameter for passing and establishing the same usr for security.

Or should I have the main app instantiate all the different pieces for all applications. Having separate databases helps seperate the data files, but having combined classes, reports, etc will number hundreds of jumbled together libraries and files.

What do you suggest for only requiring one logon and have that be used in all projects that might be called? Or Is it possible (preferred?) to have one application object be shared between many projects?

I quess my problem is understanding the differences between a complete MM project say "General Ledger", and the same General Ledger application when it is a sub project of a "main" application project with regards to sharing a logon, how are the application object(s)handled: shared or one for each, etc.

Everything in the developers guide did in fact guide the creation of a working project. It now feels like I am exploring uncharted territory and taking a beginners stab at how to take the next step to attach several MM projects together onto a larger project.

What is the best way to have a good foundation for building and integrating all 14 sub applications into a logical comprehenisive package that can be mixed and matched easily (not everyone will need all 14 applications)?

I appreciate any further ideas you have.

Gary Pike.