Item 1 provides more flexability, but is more code to write. It's basically
your middle tier layer which allows for the separation of church and state
(business / display logic). So say you create a structure to pass data
back and forth, then changes in the business code are less likely
to break the dialog code and vis-a-versa. If need be you can also
copy the data structure to use while the dialog is being displayed.
If the user presses OK, then update the original data, otherwise throw it
away.
Item 2 works too, but breaks the design rules for OO style hiding of data.
Another option instead of item 2 is to use public getter/setters on the
private properties.
Either way they allow for data binding of variables to dialog control items.
In the end it's pretty much on a case by case need and the architecture of
your application for which way to go.
Paul
For programs that have complicated dialogs, do you pass settings around by:
1) make a custom object per dialog to contain the settings, and pass it from the main program to the dialog, and back.
2) give the dialog private properties, and fill them in before showing from some variable global to the program, then re-gather properties at end before closing the dialog?