Here is a sort of compromise point of view from Jim Booth's Effective Techniques book, which I've been reading a lot lately:

"How about the situation where I'm actually launching Form "B" from Form "A," and I want to pass some god-awful complex set of information to Form "B"? Yes, I could pass a whole bunch of parameters, or even some kind of specialized object. On the other hand, my launching code could look something like this: (Note that this contradicts some of what I've said previously, but read on.)

DO FORM FormName NAME ThisForm.oFormLaunched
ThisForm.oFormLaunched.cCust_ID = ThisForm.cCust_ID
DIMENSION ThisForm.oFormLaunched.aCustList[ThisForm.nCustomers]
ACOPY(ThisForm.aCustList, ThisForm.oFormLaunched.aCustList)

As I'm sure you noticed, this code represents a couple of pretty tightly coupled forms. Manipulating a form's properties requires a lot of knowledge about that form. However, this is the kind of thing that could be built into the foundation classes or application framework, so that the properties being manipulated, or the methods being called, are not unique to a single form, but part of every form of a particular type in the system."

One important thing about Jim's example is that the calling form is manipulating the called form's properties (presumably those of an important base class), but not its controls.

>Ken,
>
>Yes, both client app and form must subscribe to the interface of the parameter object, so they are coupled. There is always coupling in a system.
>
>But accessing the internal objects of the form is an order of magnitude more coupling. You now prevent the form from changing to use alternate controls (changing a textbox to a cbo, or moving controls to a pageframe for example) without breaking every client of the form. You can bind the form directly to the parameter object's properties so it really isn't that difficult to use.
>
>
>>I understand and agree with your observation, but disagree that it matters. While I am all in favor of blackboxing many things. decoupling is not the holy grail - at least not within a homogenous application. On the other hand, I doubt there's much code/performance cost (if any) in doing it with an object, so it's worth thinking about.