>>The simplistic way is following:
>>PUBLIC gVar1 && it's better to use oApp property here
>>gVar1=""
>>createobject(...) && and reset gVar1 in e.g. Newform.Destroy event
>
>Ed,
>
>The above code works exactly the same way if the var is NOT declared PUBLIC. The only time a PUBLIC declaration would be needed would be if the program above was going to return and then some other program needed to access the variable. If this is the case then there is a design problem since the program that will use the variable did not create it.
>
>I know that YOU know this, but I sense that many others do not know this adn that there are alot of variables being delcared as public unnecessarily. PUBLIC variable remain defiend long after the program that defines them is gone. PUBLIC variables have the potential of stomping all over everything else that is in memory at the time they are declared. The only safe way to declare a memvar public is to release it first, because if there any var with name anywhere and error will occur on the PUBLIC line. That means if;
>
>IOW, PUBLIC is a dirty word and should not be typed in any program. The requirement for "global" variables can be met by creating the variable in the startup program (the one with teh read events).
>
>Otherwise the code you posted would be fine for getting the value back fromt eh called form.

>I don't quite understand your discussion of PUBLIC. From what I read, the desgnation simply extends the scope of the memvar so that it does not go out of scope no matter where the application leads. Pre-allocating all memvars in the 'MAIN' program would probably reduce memory fragmentation, but overcommits memory for those memvars not referenced in a given execution of the application. I have thought it would be a nice feature to be able to control memory de-fragmentation so we could have complete control without the aforementioned memory overcommitment. PS, I tried delcaring the memvar lcTest by assigning it a value, and then declared it PUBLIC and did not get any error indication. The value assigned to the variable was still intact and the scope of reference was increased from 'current procedure' to 'global'. Again, I must be missing something in the discussion.