Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Kickin around memory variables?
Message
From
25/05/2001 12:42:52
Gerry Schmitz
GHS Automation Inc.
Calgary, Alberta, Canada
 
 
To
25/05/2001 03:08:17
Cetin Basoz
Engineerica Inc.
Izmir, Turkey
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00510941
Message ID:
00511603
Views:
21
>> With the way Steve creates (controlsource=m.something) variables are not private but public. For that reason I tried hard to say he needn't to declare as public but a refresh problem. He'd see variables even after closing the form in memvar list (if just walked pages w/o setting focus to boxes then only the first page set, if setfocus to all at sometime then all - I don't know the reason possibly performance consideration).<<

I have found no evidence that [.ControlSource = "m.Something"] ever creates PUBLIC variables; if Steve has found a way, I would be interested in seeing an example. eg.
   o1 = CREATEOBJECT( "My_Form" )

   DISPLAY MEMORY LIKE cName

DEFINE CLASS My_Form AS Form
   ADD OBJECT txt1 AS TextBox WITH ControlSource = "m.cName"
ENDDEFINE
The above sample illustrates that m.cName is "created" and is PRIVATE. It will even stay in scope if CREATEOBJECT is performed at the "highest level", perhaps the same place as the (main) READ EVENTS, though that is highly unlikely within most frameworks. Typically the CREATEOBJECT would be within another subroutine and the (dynamic) "ControlSource variables" would go out of scope.

The fact that VFP creates them at all is probably more to do with being able to "DO a Form" at Design time than for any real run-time considerations.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform