>>>>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).
>>
>>if app executes MAIN at startup,
>>SET PROCEDURE to MAIN is implicit
>
>Yes, that would be true within the compiled program (as long as Main.PRG is within the call stack when the dependent code executes). However, this would not be the case when trying to run the form code interactively within VFP (which is what the original post was asking about).


Wahoo, congrats for understanding that, you can probably better read between the lines than I do.
@OP: please spend a little more time being more specific (such as posting code and errors), that'd save our time.