I think you are on target! I do not issue another read events within the second application so the focus is probably going back to the first with no referenct to the second (as you said). I thought I worked around that by having a 'set procedure' to the app file. Your hypothosys is supported by the nature of the app running fine from the command window.

Does the solution now require having two apps? One to display the menu pad with prompts and another to act as a loader that is called from the menu prompts. This seems sloppy; I remember doing things like this in earlier version of Fox without this complexity. I understand things change, but I always thought it was supposed to be for the better!


>Just to support your idea: Although I've never had a need, there are some good reasons for using multiple exes like you're doing - mainly support: If a change is made on one function, just upgrade that one, smaller exe. I know several people who do this and it works well for them.
>Back to your problem. You say that your second exe creates a menu pad that activates functions within the exe. I assume this is a pad added to, rather than replacing, the existing one (??). After the menu pad is added, what happens? Do you issue another READ EVENTS? If you just return, you're returning again to the main app, which has no reference to the second. If this is the case, your second app has to function more as a function library, in other words your menu pad should call the second exe with a request: DO ExternApp.exe with "Customer List", or whatever.
>
>Am I getting close?
>Mark
>
>>Thanks. The second app is simply a project built with a menu as the main procedure. This menu is a single pad with negotiation that each option calls a different form that is included in the project. If I run the app from the command window it works fine, but if I run it from the host exe, the menu pad does appear as intended, but when I select an option, I get the file not found error. This app is being moved into a different directory (production) from the directory where it was created, but my understanding is that the app has all included files built into the app file itself. I would hate to have to include all files from the second app in the host project since this will contamonate the generics of the host. The host is a large application within itself, all I want to do is add additional functionality for a specific group of users.
>>
>>
>>>Troy,
>>>I assume you've got calls to these external apps within your main app that is basically:
>>>DO ExternApp.exe
>>>Does ExternApp.exe run fine if called from the command window? Is it installed in a separate folder than the main app? Do you have explicit references to files within the external app, like do c:\externapp\start.prg? If the app is moved to another folder, this will generate "file not found" errors, even if start.prg is compiled into the app.
>>>
>>>Mark
>>>
>>>>If I were to have an EXE file call another EXE or APP file, shouldn't the files in the second file (APP or EXE) be visible?
>>>>
>>>>I have a generic application which I want to call specific app or exe files that add a menu pad to the host application. This part works well, however, when I try to use the options in the new menu which is added by the second application, I get errors telling me the files are not found (screens, reports, menus, programs, etc).
>>>>
>>>>These files were included in the project that was used to build the app.
>>>>
>>>>I even tried to set procedure from the host application to the app file without luck. The only solution seems to include all source files with the app or compile the app into the host project which makes a terrible mess of the host project file and defeats the purpose of seperate app files.
>>>>
>>>>Please!
>>>>What is the solution?