Charlie,

Thanks. This is very helpful. In the meantime, I got Stephen Sawyer's/Jim Booth's book 'Effective Techniques' book. It was very helpful to me because they write very clearly about the issues of loose coupling vs tight coupling between forms, which helped clarify my thinking. This appears to be what you are getting at here as well. I think that their idea is that ideally you want to strive for loose coupling, but in some individual cases, it may make more sense for forms to be tightly coupled.

David


>Hi David,
>I like strategy 2 better than 1, but I'm sure 'it depends' is the more complete answer. FormB's job is to gather certain information. Theoretically, it could work and not even know what info it was suppose to collect--just march thru the property object and show an appropriate input control. The form only has a default OK and Cancel.
>Another strategy is to leave some pertinent facts around so FormB can know what record to default to. This way FormB doesn't have to be modal. Let's say you have a generic address form. By default, when it comes up it asks the application object for the primary key to show--normally just the last one shown--perhaps a ThisApp.GetSettings("Address"). But if FormA did a ThisApp.SetSettings("Address", MyAddressKey), FormB would just naturally show the desired data. In our framework, when FormA.Activate runs, it requeries to update any stale information, so if the user saved in the Address form (FormB), the fresh info would be displayed. The advantage here is that FormA and FormB aren't so closely tied. They each just do their jobs.