>>>In the form Init I have put do main.prg, and set default to the proper folder, but it runs into all sorts of errors that are not there when compiled. Drives me nuts - lol!
>>
>>I don't think you should be putting DO main.prg in the INIT of the forms -- you'll have to remember to remove that before you compile (otherwise you'll generate more problems). What I'd suggest you do is create a "stub" program that sets up the environment while you're in VFP, then run it just after you start VFP. Of course, this means you have to remember to DO stubprog each time. One way around this is to create a CONFIG.FP that has a COMMAND line that has the DO stubprog, then reference that from the shortcut that you're using to launch VFP. Rather than modifying the main shortcut to VFP, create a new one that is specific for the project.
>>
>>What I've been doing (since the FoxPro days) is to have a "projects" folder, into which I've set up sub-folders -- one for each project that I'm working on, each with its own CONFIG.FP, resource files, and anything unique to the project, then set up shortcuts to VFP for each of the projects. To avoid desktop clutter, I've set up toolbars to contain those shortcuts. One potential advantage is that in creating separate "environment" through the CONFIG.FP (which also sets up a project-specific resource file) is that I can maintain a separate environment for each project. To deal with the numerous shortcuts that would result form this, I organize the shortcuts into a toolbar (into which not only would I have project-specific shortcuts to VFP, but also to any external programs or files relating to the project).
>
>I'm confused - why not just use the SET PROCEDURE command? Like SET PROCEDURE TO MAIN.PRG ???

a SET PROCEDURE sets up the references to any UDFs and procedures defined in MAIN, but doesn't create and assign the PUBLICs, nor does it handle anything like SET DEFAULTs or SET PATHs or other environmental settings. Yes, you could do a DO MAIN -- but that could also trigger stuff like changes to the system menu as well -- which is likely to be a pain if you're trying to use the development environment.. That's why I'm suggesting a "stub" program that sets up the environment -- which could include any publics that may be assumed to be declared in the form code. Yes, it's bad form to have that in the form code, but if you're starting out with form code that was already made, you can't do much about it without having to recode (which is likely to make the update more involved).