>Hi Ed,
>
>>The easiest way would be to make them properties of the form, rather than variables. The only memvars that would persist would be globals (PUBLICs) and there are all sorts of funky side effects, on top of being bad OOP in general. Form properties are visisble within the form, and have the necessary persistence and encapsulation you want.
>
>I've thought about this in the past, would it be agaisnt OO to create an oGlobalVars object that sits like an oApp, but you wouldn't want to bog oApp down with somewhat un-relavant variables? The property would create its self using an AddProperty in a this_assign. I realize this would not (or should not) be used alot. But from returning a value from a NewObject or something just plop that Var in oGVars.
This would be better than public variables, because the accessing syntax would at least have to use the object name to get to the property, and so local variables wouldn't stomp on the globals, but IMHO, it's still bad design.
Almost always, in my experience, there is a way to classify and/or group variables like these, and put them in an object where they logically belong. But to be honest, most things like this I put in my application object. But there aren't many. What kinds of things do you propose might justify a generic "variables" object?
Erik Moore
Clientelligence