That's why I was thinking of the EXTERNAL FORM command. If I used macro substitution like DO FORM (goform) then I would need the EXTERNAL FORM command before declaring the value of goform. I have a lot EXTERNAL ARRAY lines in the FDP26 app for undeclared arrays in called programs. I found it that it was added because it was taken from code that was automatically generated during anther FPD26 screen conversion to VFP7. When converting forms, that line EXTERNAL PROC is added and the form is called in quotes like DO FORM "goform.scx" go figure.

>Tracy;
>
>Somehow brings back memories of indirection to pull the form into the project, but the Proc bit is not self-explanatory.
>
>Which approach works? Go with the one with the least code! :)
>
>Tom
>
>
>>Below is code in a VFP app that also runs in FPD26. The FPD26 version runs a screen and the VFP version runs a form:
>>
>>

>>#IF !'VISUAL' $ UPPER(VERSION())
>>	DO co_prnt.spr
>>#ELSE
>>	DO FORM co_prnt.scx NAME oco_prnt LINKED
>>#ENDIF		
>>

>>
>>One of my coworkers modified it to now be the below code:
>>
>>

>>#IF !'VISUAL' $ UPPER(VERSION())
>>	DO co_prnt.spr
>>#ELSE
>>	EXTERNAL PROC co_prnt.scx
>>	SET KEYCOMP TO DOS
>>	DO FORM co_prnt.scx NAME oco_prnt LINKED
>>	SET KEYCOMP TO WINDOWS
>>#ENDIF		
>>

>>
>>My question is why add the EXTERNAL PROC line? Isn't that NOT necessary in VFP? All functions running in the vfp8 form are contained in the form itself as properties of the form. I could understand a EXTERNAL FORM command if I was using macro substitution, but I'm not.
>>
>>TIA,
>>Tracy