Troy,
The problem is this: after the second exe loads the menu and returns, all functions, forms, etc.. within that application are no longer linked to the current process. The only way I can think that this could work 'as is' is if the functions existed as separate PRGs, installed near the main app, so that they are called separately from the menu pad (or elsewhere in the main app). Otherwise, to access functions within that exe without it being currently run, you must use it as a loader, as previously mentioned.
I have created apps like you're doing, before: They load a menu pad and return. I simply use code like:

ON SELECTION BAR 1 OF popMyMenu DO MyFunction IN &pcProgPath

..where pcProgPath is the path of the second exe. If this path is relative to the main app, and does not change, you can hardcode it in. Otherwise, you can get the path with SYS(16) in the main PRG or form of the second exe.

HTH!
Mark


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