You're describing a "Push" mechanism here: App A creates App B and calls something in App B.

You might consider turning that around: App creates App B (as before) but then App B somehow "Pulls" from App A, or from a structure created by App A, which is kept in an agreed place (a directory or a database or a message queue).

In other words, A calls B, and B returns control immediately. Meanwhile, in B, a timer was launched that independently of the call from A goes to the agreed place (directory, table, or queue) and parses the structure that was left there by App A...

There are lots of ways to do this, but in a nutshell that's one way.

**--** Steve


>We have two fully developed independent monolithic applications one written in VB and one in FoxPro. A requirement has arisen that each should be able to launch the other and make it display a particular record by the passing of parameters.
>
>Here is the tricky bit: having got both applications running, the user should be able to navigate to a record in either of the applications and then click a button to bring forward the other application and at the same time make it navigate to its equivalent record.
>
>Because of this need for ongoing communication between the two applications I felt that it would be better to use COM rather than just have one application RUN the other.
>
>The snag is running the FoxPro application from the VB one causes the VB application to hang until the user closes the FoxPro one. The VB code would looks a bit like this:
>
>oFoxApp = CREATEOBJECT("MyFoxApp.Application")
>oFoxApp.Launch()
>
>The MyFoxApp.exe contains an OLEPUBLIC class library called Application.vcx with a method called Launch. The Launch method calls the Main.prg.
>
>The problem seems to revolve around the READ EVENTS command. If it is included in main.prg then the Fox application works fine but the VB one hangs on the oFoxApp.Launch() command until the Fox application is closed, if one the other hand the READ EVENTS is removed then needless to say the Fox app runs up and immediately closes down and the VB application does not get hung.
>
>I guess there might be a completely different way of approaching this - thanks in advance for your suggestions.
>
>Richard