>>As vfp is basically prototypal, calling a function in the base class to set the property should only run once.
>>Next classes of that base class just copy properties from first one and run defined methods.
>>But you have put that code/call either in property window if vcx based or in the "declaration area" just after "define class" in prg based class - NOT in .init() or any other function of base class. Check by adding a log entry or wait window...
>
>You misread a bit - he intends to run some code to check for a global setting, during the instantiation of any label, and "base class" is of course not Label but MyBaseLabel. So the antediluvian question of OOP says "where does the code go?", and in this case MyBaseLabel.init() is the place.

I think I interpreted his intentions correctly, even if the effect is less damaging as he fears.

The MyBaseLabel.init() the code will run for EACH label put on any form, creating a minuscle time lag. But if this is done for dozens of properties for hundreds of labels, users will notice. The .Init() is NOT the place, only the inheritance level is correct, as this enhanced example of vfp help proves

oDef = CREATEOBJECT("defaultgiver")
frmMyForm = CREATEOBJECT("Form")
frmMyForm.Width  = 450
frmMyForm.Height   = 100
frmMyForm.Caption  = "Scope Resolution Example"
frmMyForm.AutoCenter =.T.
frmMyForm.AddObject("cmdQuit","cmdQuitButton")
frmMyForm.AddObject("cmdAnother","cmdAnotherButton")
frmMyForm.SHOW       && Display the form
WAIT WINDOW oDef.nCount NOCLEAR NoWait
READ EVENTS        && Start event processing

DEFINE CLASS defaultgiver as Custom
  defColor = RGB(127,0,0)
  nCount = 0
  PROCEDURE defColor_ACCESS()
  	this.nCount = this.nCount + 1
	wait window "Called" + STR(this.nCount) TIMEOUT 1
  	RETURN RGB(0,0,255) && Change button text color according to user defined setting from ini/dbf
enddefine
 
DEFINE CLASS cmdDumbButton AS CommandButton 
  PROCEDURE init
    this.ForeColor  = oDef.defcolor &&Change button text color by running same code in EVERY label AGAIN
ENDDEFINE

DEFINE CLASS cmdSmartButton AS CommandButton 
  ForeColor  = oDef.defcolor && Change button text color ONCE via a method
ENDDEFINE

#if .f.
DEFINE CLASS cmdQuitButton AS  cmdSmartButton 
#else
DEFINE CLASS cmdQuitButton AS  cmdDumbButton 
#endif

  Caption  = "\<Quit " + Proper(this.parentclass)  && Caption on command button
  Left   = 95    && Left edge of button
  Top    = 60     && Position for top of button
  Height   = 25     && Button height
  Width	= 200
  Visible  = .T.    && Show button on form
  FontItalic = .T.    && Turn on italic text
  PROCEDURE Click
	  WAIT WINDOW "Executing the CLICK procedure for cmdQuit." TIMEOUT 1
	  CLEAR EVENTS     && Stop event processing

ENDDEFINE

DEFINE CLASS cmdAnotherButton AS cmdQuitButton
  Caption = "Click " 
  Top   = 30
  PROCEDURE Click
  WAIT WINDOW "Click event for button: cmdAnotherButton" TIMEOUT 1
  cmdQuitButton::Click
ENDDEFINE

>Now what you say about "calling a function in the base class to set the property should only run once." is not what I observe while debugging. Simply because the code may not be generic, but may refer to this or this.parent or who knows which instance specific property. So it runs every time, for every instance's .init(). There were cases when I hated that (because I had to wait out dozens of controls' init()s to see what's up with a particular class of control which was misbehaving only in a very complicated form, on pgf2.page9), but there it is.

The _Access Method is run only once for ALL the smart buttons used inside the app, but EVERY time for EACH dumb button, which is caused by putting the code into .init() instead of setting the property default for each user without involving the .init() of EVERY label.

Just change the base class by editing the "#if .f." and compare the runs shown in wait window noclear.

Or if you'd like more abstract definition, think of Javascript ALWAYS writing to the object instance, but reading up the inheritance tree until encountering the prototype level the property is first defined by writing to it. Setting the default value outside the init method is performing a caching of the "get personal default value for that property from data store" done in the init to write to the object instance on the prototype ONCE.

regards

thomas