>>One alternative is to pass an object reference to the form you are calling, then use this object reference to set properties or launch methods in the calling form.
>>
>>For example:
>>
>>Calling code:
>>
>>
>>Do form NonModelForm with thisform
>>
>>
>>Init method of form that is being called:
>>
>>
>>parameters oCallingForm
>>thisform.oCallingForm = oCallingForm
>>
>>
>>Now anywhere inside of your form you can reference the calling form easily...
>>
>>Example:
>>
>>
>>thisform.oCallingForm.UpdateForm()
>>
>>
>>
>>Of course you can use this to pass an array or any other data type to a method in the calling form.
>>
>>I've found this design very flexible in updating forms and passing complex data back and forth without parameters or global variables.
>>
>>Greg
>>
>>
>>>if you want to return a value from your form you have to do modal your form even you don't return array. So you can declare your array before form and use it in form and after form without any describtion.
>
>Good plan. But there's one thing to think about before using it. The called form must have knowledge about the used form. Any time that the used form will be changed, the code in the called form needs revision. I don't mind, but some OO purists will object.
Well I've never been too much of a 'purist' anyway. I would like to understand better what OO purists objections would be and what they would recomend to make the coupling more 'correct'.
I thought the purpose of passing the form object and calling it's 'UpdateForm' was specifically to keep the called form from needing to know any of the details. All I'm doing is invoking the method and it's up to the calling form to do what it needs to do without regard to the called form. So the only circumstances i can see having to change UpdateForm would be if it has to do with specifics regarding that form alone.
I'm very curious what the preferred technique would be.
