>>I want to add functionality from one of my applications (an accounts app) into another.
>>
>>I know I could just add all the code and forms to the 2nd EXE but that would make the EXE very large and maintenance much harder. I have played with "DO mProcess IN .." etc. but most of what I want is calling forms not procedures and there is no "DO FORM MyForm IN ..."
>>
>>I know I could make things OLE public and do createobject() but I don;t want the overhead and the loss of direct control that offers.
>>
>>Interested to know what others do and what the performance hit is?
>>
>>Gary.
>
>
>Having a large .EXE file is not a big issue. The typical way to handle updates in a multi-user environment is to use a launcher.exe app which determines which version should be run (the latest, for example) and then launches it. That way every time you release a new version, just copy it to their exe\ folder and then have them restart the app.
>
>In the alternative, pass the name of the form you want to run as a command line parameter:
>
>

* There's also a create process class around somewhere that you could use instead of RUN
>RUN /N my2nd.exe myForm foo.dbf
>
>* As first source code line of my2nd.exe:
>LPARAMETERS pcFormName, pcTableName
>
>    DO CASE
>        CASE LOWER(pcFormName) = "myform"
>            DO FORM myForm WITH pcTableName
>    ENDCASE
>
>* The pcTableName indicates a file that contains parameters you would've passed to that form, if any
>

>
>This will allow the my2nd.exe program to launch and go immediately to the indicated form.
>
>Hope this helps.

That's pretty much the method that we'd arrived at back in the MS-DOS days. At the time the main motivation was to allow us to use floppy diskette as distribution medium, as at the time we weren't using an installation program (we were using a batch file) and there wasn't a convenient method to allow us to have files that could span multiple diskettes. I'd suggested we break up our application into separate "components" (and using parameter-passing to tie everything together) to get everything to fit on floppy diskette -- there was one "master" EXE and "modules" that consisted of APP files. Though it did take a bit of time to adapt the existing code to work in that fashion -- but eventually gave the benefit that we could more easily deal with bugfixes, updates and customer-based customizations. It goes without saying that you need to make sure that you have a method to check version/revision information of the various "modules".