Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
OverRiding SubClasses at RunTime
Message
From
05/05/1998 10:39:03
 
 
To
04/05/1998 22:55:44
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00096608
Message ID:
00097021
Views:
24
>You're doing great and you are correct in every respect.
>
>>> Now my concern is that with n forms open, I’m going to have n copies of my oPreference object in memory.
>
>Good point! Here are things that mitigate that. First, when Fox creates an object, the user code and default object properties occupy a single memory instance. Thus if you have 10 instances of class KickADeadWhaleDownTheBeach, all the user code and all the default properties for all those instances are kept in a single memory location. Internally, the only things that are replicated are structures to map individual object read-write properties.
>
>Secondly, the "oPreference" class could itself be a lightweight class. Classes Line, Shape, Custom, Separator are all real light weight. If you can deal with class in a .PRG, classes Relation and DataEnvironment are the lightest of the lightweights.
>
>Thus you could write, in code
>
>DEFINE CLASS MyPreferences AS RELATION
>  FUNCTION Execute( toControl)
>    IF TYPE( "toControl.BackColor")= "C"
>      toControl.BackColor= COL_CHUNKY_BARF
>    ENDIF
>ENDDEFINE
>... and you could have 30 of these in memory and still take far fewer resources than the a single simple form, or a single simple combobox for that matter.



You have an interesting include file ... COL_CHUNKY_BARF ?

I’ve had a few breakthroughs as I have worked with VFP. Understanding dodefault() was the one that opened a lot of doors for me. This is where I first really understood inheritance. Another breakthrough was when I realized that SCX’s and VCX’s were really DBF’s. I like working at a low level and I’ve had some good experiences snooping around in (and occasionally modifying) the Memo fields. Now with you using RELATION as the basis of your sample class, a bunch more lights have clicked on. I never would have considered using anything other than CUSTOM. Another layer of magic has just been striped away.

The common memory location for multiple instances of the oPreference class’s code and default properties came as a surprise. If I’ve got it right, I think you are saying that a parallel, writable version of each of the class’s properties is created at instantiation for each instance of the class and its these writable copies that I am actually reading (and potentially writing) ... a little like private datasessions for class instances.

While I’m at it, what is the IF TYPE( “toControl.BackColor”) = “C” protecting us from? That is, how could our control not exist if we are passing only controls found in our form with FOR EACH oControl in THIS.Controls

PS I’m sure glad I’ve adopted the recommended VFP naming conventions, I really would have been lost trying to keep up with this discussion without all those great little o’s, c’s, and t’s.

Bob
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform