Hi Larry:

>This seems to be kind of messy. It might be the case that the whole CM application should quit, before starting up FoxFire.

Seems a bit drastic <s>.

>1. The FFSTART is actually a call to ffstart.exe. The project manager attempts to compile this into the project, when I try to build the app.

You could modify your openff.prg so that instead of DO FFSTART, you call it like this :-

DO ("FFSTART.EXE")

This will run FFStart.exe using the name expression, but, it will not try to pull it in to your project build/compile cycle. You could also use macro expansion to call FFStart or use Eval(), something like ... Eval("FFStart()"). These approaches will run FFStart but will fool the compiler.

> if I try to do a preview the preview window never shows up. FF is running within the CodeMine window.

I know nothing about FoxFire so, I can not really say what is happening here. However, can FoxFire be called modally? If so, that may help.

>2. How does the running of this affect the datamanager and the statemanager?

As far as the datamanager goes, that really depends on what Foxfire does with its table/data handling methods. I can't really see why Foxfire would have any real impact on the datamanager unless it opened/close manipulated tables/views that are already being handled by the datamanager. As Foxfire is a developer tool, it would seem unlikely that it does not use its own private data-sessions to handle its own data requirements. If in doubt and you are using VFP6 SP3+, you could modify your openff.prg and using the new session class, create a new data session, change to it and then call FFStart. When, you are finished in Foxfire, just close the old data session and switch back to the original session hosting your Codemine app.

As for the statemanager, again, I can't see that running Foxfire will have any impact on defined states. Foxfire knows nothing about them and is not privvy to the Codemine statemanager object (cmStateManager). So, I can't see this being an issue for you.