>Jim, You are misunderstanding what I am saying, I was describing how statics in other languages work. Static member variables in C++ are shared beween all instances of the class, they are analogous to public variables that can be accessed only by members of the class. From Classical Algorithms in C++ by Nicholas Wilt, page 321, "When applied to a data member of a class, static makes it persistent within the class; that is, not every instance of a class contains the member. Static data members of the class should be thought of as global variables belonging to the class." I know this descriptions is correct because this is how they behave in my programs that use them.
>

Albert, in the rare instances I've needed this, I've instantiated another object to hold the static values, and embedded a reference to the static object carrier in each object instance that needed to use the static property. This has the advantage of also giving me the ability to serialize access to the static member, essentially a means to implement MUTEX for critical blocks of code using the static property as a semaphore (a good place for using an ASSIGN and ACCESS method for a property; they can also be used to restrict visibility of the 'statics' by checking the class of the object referencing the property.)

IOW, create an object like:

DEFINE CLASS Statics AS Line
   nStatic1 = 0
   PROTECTED lStatic1Busy
   lStatic1Busy = .F.

PROCEDURE nStatic1_ACCESS
   DO WHILE this.lStatic1Busy
   ENDDO
   RETURN this.nStatic1
ENDPROC

PROCEDURE nStatic1_ASSIGN
   LPARAMETER nNewValue
   IF this.lStatic1Busy
      RETURN .F.
   ELSE
      this.lStatic1Busy = .T.
   ENDIF
   *  If something that took measurable time to complete were involved,
   *  other class instances would wait to read the value, and they'd
   *  be denied the ability to assign a new value to nStatic1
   this.nStatic1 = nNewValue
   *  Now we release the 'busy' flag so others can read/write
   this.lStatic1Busy = .F.
   RETURN .T.
ENDPROC

ENDDEFINE

Pass the object reference to the statics instance to each object that needs to access the static member...

>This behavior is desirable for many applications and I would find it very handy in VFP. For example, I would love to have a static proberty in which the first instance of a clss stores a reference to itself. Subsequent instanciations would see that the property was initialized and not instanciate, they would instead return the reference stored in the static property. The reference can be returned in a parameter (even better would be if MS changed the handling of objects so that the init method could return an object reference).
>
>Sure you can use halfassed techiques like declaring a public variable that the class uses to emulate the behavior. The problem is that as plain public variables, they can be stomped on or even released by outside code. All OOP can be implimented in procedural languages (the first C++ implimentations were preprocessors for C compilers), I find it better when a language directly supports the paradigm in its syntax. Your approach has as much merit as simulating inheritance in Visual Basic.
>
>
>>Albert,
>>
>>That is incorrect. A property of an object may be defined in its class but the value belongs to the object.
>>
>>Object oObj
>>Method: readval, setval
>>Property nVal
>>
>>Code:
>>
>>

>>oObj = CreateObject("Obj")
>>oObj2 = CreateObject("Obj")
>>oObj.SetVal(125)
>>oObj2.SetVal(250)
>>?oObj.ReadVal()  && 125
>>?oObj2.ReadVal()  && 250
>>
>>DEFINE CLASS Obj AS Custom
>>
>>nVal = 0
>>
>>PROCEDURE SetVal(pnVal)
>>  This.nVal = pnVal
>>ENDPROC
>>
>>PROCEDURE ReadVal()
>>  RETURN This.nVal
>>ENDPROC
>>
>>ENDDEFINE
>>

>>
>>The property nVal is encapsulated to each instance of Obj and is static in that is retains its value between calls to the object. The property is visible to the object at all times during the object's existance.
>>
>>STATIC vairables are not necessary in VFP. They can be helpful in certain situations, but using objects can always get around the requirement for STATICs.