Jim,

I ran into this old message from you. Do you have additional suggestions on how to make a more complete parameter object class?

TIA,

Alex

>Having the calendar form make changes to the calling form's properties is a bad design. The calendar form should not be changing anything in the callinf form. Instead use a parameter objerct that is passed to the calendar form as in;
>
>

>* ParamObj.prg
>DEFINE CLASS ParamObj AS Relation
>
>PROCEDURE Init
>   This,addproperty('RetArray(1)',"")
>   DIMENSION This.RetArray(1,2)
>   This.RetArray = ""
>   RETURN
>ENDPROC
>
>ENDDEFINE
>

>
>Now when you call the calendar;
>
>

>* some method in the calling form
>loParam = NewObject("ParamObj","ParamObj.prg")
>DO FORM Calendar WITH loParam
>ldMyDate =  loParam.RetArray(1,1)
>* Now do what you need with the date.
>RETURN
>

>
>Here's the code inside of the Calendar form;
>
>

>* Calendar form Init
>LPARAMETERS poParams
>This.AddProperty("oParams",poParams)
>

>
>And later in the calendar form's Destroy
>
>

>* Calendar form's Destroy
>This.oParams.RetArray(1,1) = This.Date
>RETURN
>

>
>Do this this way removes any dependance of the claendar form from the form that is calling it. All manipulation is done to ther parameter object that is being passed around. The technique can be expanded to have the calling form put values in the parameter object that the calendar form reads for information and then teh calendar form posts the results in the same parameter object. This technique removes the issue of the calendar form making chang4es directly to the form that called it and it removes the whole garbage about hiding the clasendar and leter destroying it (or forgetting to and leaving the calendar hanging around taking up memory).