Tracy,

450 screens, YIKES!

If you have VFP8, use the Code References tool to help find ALL instances of those vars you're replacing to make sure you catch them all. You can use it to help analyze your 2.6 screens, as well as the new VFP forms. If you're stuck with VFP7 or earlier, use one of the project search tools available in the UT downloads section to accomplish this. Since you have so much code to plough through, everything you can automate will be a huge plus at crunch time.

Also, the .AddProperty() method of objects (like the form) can be handy for quickly storing a value that needs to persist throughout the life of the form, without having to add that property to the class definition. You could use that technique in the Init() method to "simulate" the var declarations your original post asked about.

Best of luck!



>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