Hello Tracy,

We all agree that using object properties is the best option, however, on conversions like this it may not be always practical.
I know this thread has been around for a while, and I may repeat what others may have suggested already, but here is my thought;
- Wrap each form in a PRG where you declare all the PRIVATE vars that are expected during the execution of the form. Name the prg something like ~FormName~prg. Thus each form will have a wrapper that will emulate the Setup/Cleanup sections from the FP screens.
- In your calling programs instead of DO FORM myform, call DO myformprg which (is the wrapper that) declares the PRIVATE vars that will live throught the execution of myform., calls DO FORM and does the clean-up after the form is released.

Sorin

>Hi John,
>
>I think we all vote for form properties for the obvious reasons. The issue is more a 'temporary' one due to time and deadlines. 450 FPD26 screens to convert by January 1st to go live February 8th. Over half of the screens are multipage and require at least 150 variables (in the current configuration) so the time involved to change all vars to form properties and also the logic where every var was accessed is time consuming. Also most forms are only allowed to run once but can be called from multiple locations in the program. I think in the long run it will be entirely form properties of course but in the short term the time just isn't there to accomplish it all. This deadline has already made me rather 'brain dead' in a lot of areas :o) trying to accomplish as much as possible in day that now runs 16-18 hours of programming 7 days a week.
>
>Tracy
>
>>Dragan
>>
>>In the supplied code, surely a variable defined above the Createobject() will go out of scope immediately after xform.show, since that is where this procedure must end.
>>
>>I vote for form properties.
>>
>>Regards
>>
>>j.R