>You are correct, there are a bunch of shared class libraries and all the forms, are in a single folder, reports in one, etc.
>
>I see what you mean and get most of it. However, are you saying I should put my application Object (I call it oApp) in the main project along with my menu? Then on my menu bar when something is called, how would I call it? Do xxx in xxx.App?
>
>Thanks.
>
>Mike

Mike,

Just call the point of entry.

For example;

In the File menu, I might have a sub-menu for "Modules" wherein we find the heading "General Ledger". When the user selects General Ledger, I would call MyGeneralLedger.app.

Now I would use a loader method of my Application Object, so my call would go more like this.

oApp.LoadModule("MyDrive:\MyPath\MyGeneralLedger.App", "General Ledger")

***********

oApp.LoadModule would look something like this ...

*/ oApp.LoadModule() :: Load an associated module for use
LPARAMETERS cModuleFile, cModuleName

LOCAL ;
nModuleIndex && Module number (as loaded) if it is already loaded.

nModuleIndex = ASCAN(THIS.Modules, cModuleName)
IF nModuleIndex > 0 && It's already there
*/ Return the reference to the module in the collection
RETURN nModuleIndex
ENDIF

IF NOT FILE(cModule)
*/ The file can't be found
RETURN (an error code)
ENDIF

DO &cModuleFile
*/ I'd check for an error during init of the .app and handle it here,
*/ returning an error code from the method.

*******

One could get very involved in setting up object references to the modules (Probably the best way). One could also get very involved in error handling, and messaging between the modules.

But this is in essence how I would approach the problem.

Regards,

J.