Ed:

Good example, Thx!


>>>>>>>>>>>>>>>
>>On this last point, is there a difference or a preference on using _VFP vs. _SCREEN?
>
>_SCREEN is able to support AddProperty(); _VFP does not, so that's easy. FWIW, if I'm going to repeatedly reference an object embedded in _SCREEN, I'll create a local variable to hold an object reference; for example, I often have an oHeap object that is added to my _VFP object, but when referencing it alot, I either issue a WITH _SCREEN.oHeap or will assign a local oHeap = _SCREEN.oHeap and use the local reference within the module for clarity and for the slightly reduced object traversal overhead. I also have to pay attention to doing this in my shutdown to avoid dangling object refs - I add code that assigns the added object refs a NULL to close them before quitting the app; it may be redundant, but it ensures that we don't have dangling object refs that might interfere with VFP exiting cleanly. The added code is very straightforward to implement; the main issue is ensuring that well destroy any items containing embedded references to these object
>before they're released themselves; ie if I have a NETRSC object that contains an embedded reference to my _SCREEN.oHeap, I want to release the NETRSC object before releasing _SCREEN.oHeap, which I have to address in code. One approach I've played with is to add a member array to _SCREEN, that holds the names of any properties I've added in the order these properties were added; I can spin through this list in reverse order to release the added object refs from newset to oldest:
>
>

_SCREEN.AddProperty('Props',CREATEOBJ('TrackAddProps',_SCREEN))
>_SCREEN.Props.AddProp('oHeap',CREATEOBJ('Heap'))
>_SCREEN.Props.AddProp('oFormManager')
>_SCREEN.Props.AddProp('LifeTheUniverseAndEveryThing',42)
>_SCREEn.Props.DelProp('oFormManager')
>_SCREEN.Props.Release()
>
>DEFINE CLASS TrackAddProps AS LINE
>   PROTECTED aProps[1], nNumProps, oParent
>PROCEDURE INIT
>   LPARAMETER toThisParent
>   WITH this
>      .nNumProps = 0
>      .aProps[1] = NULL
>      .oParent = toThisParent
>   ENDWITH
>   RETURN .T.
>ENDPROC
>PROCEDURE Release
>   LOCAL cItem
>   WITH this
>      DO WHILE .nNumProps > 0
>         .DelProp(.aProps[.nNumProps])
>      ENDDO
>      .oParent = NULL
>   ENDWITH
>   RETURN .T.
>ENDPROC
>PROCEDURE AddProp
>   LPARAMETER tcPropName, tuPropValue
>   LOCAL lAddProp
>   WITH this
>      lAddProp = TYPE('.oParent.'+tcPropName) # 'U'
>      IF lAddProp AND .oParent.AddProperty(tcPropName, tuPropValue)
>         .nNumProps = .nNumProps + 1
>         DECLARE .aProps[.nNumProps]
>         .aProps[.nNumProps] = tcPropName
>      ENDIF
>   ENDWITH
>   RETURN lAddProp
>ENDPROC
>PROCEDURE DelProp
>   LPARAMETER tcPropName
>   LOCAL nI
>   WITH this
>      FOR nI = .nNumProps TO 1 STEP - 1
>         IF UPPER(.aProps[nI]) == UPPER(tcPropName) AND TYPE('.oParent.'+tcPropName) # 'U'
>            STORE NULL TO ('.oParent.' + tcPropName)
>            =ADEL(.aProps, nI)
>            .nNumProps = .nNumProps - 1
>            EXIT
>         ENDIF
>      ENDFOR
>      IF nI > 0
>         DECLARE .aProps[MAX(.nNumProps,1)]
>      ENDIF
>   ENDWITH
>   RETURN nI > 0
>ENDPROC
>ENDDEFINE

>
>I use the same core logic to handle my Forms deactivation - I often save a reference to the parent form in a child; unless we update an existing form to reference new forms, releasing the Forms newest to oldest assures that child forms release before parents, releasing any object references to the parent before releasing the parent itself and avoiding dangling object refs.
>>>>>>>>>>>>>>>