Is there a standard way to return values from custom dialogs in Windows Forms?

Question

So right now my project has a few custom dialogs that do things like prompt the user for his birthday, or whatever. Right now they're just doing things like setting a this.Birthday property once they get an answer (which is of type DateTime?, with the null indicating a "Cancel"). Then the caller inspects the Birthday property of the dialog it created to figure out what the user answered.

My question is, is there a more standard pattern for doing stuff like this? I know we can set this.DialogResult for basic OK/Cancel stuff, but is there a more general way in Windows Forms for a form to indicate "here's the data I collected"?

Answer 1

I've always done it exactly the way you're describing. I'm curious to see if there's a more accepted approach.

Answer 2

is there a more standard pattern for doing stuff like this?

No, it sounds like you're using the right approach.

If the dialog returns DialogResult.OK, assume that all the necessary properties in the dialog are valid.

Answer 3

I would say exposing properties on your custom dialog is the idiomatic way to go because that is how standard dialogs (like the Select/OpenFileDialog) do it. Someone could argue it is more explicit and intention revealing to have a ShowBirthdayDialog() method that returns the result you're looking for, but following the framework's pattern is probably the wise way to go.

Answer 4

For me sticking with the Dialog returning the standard dialog responses and then accessing the results via properties is the way to go.

Two good reasons from where I sit:

1. Consistency - you're always doing the same thing with a dialog and the very nature of the question suggests that patterns are good (-: Although equally the question is whether this is a good pattern?
2. It allows for return of multiple values from the dialog - ok there's whole new discussion here too but applied pragmatism means that this is what one wants in some circumstances its not always appropriate or desirable to package values up just so that you can pass them back in all in one go.

The flow of logic is nice too:

if (Dialog == Ok)
{
    // Do Stuff with the entered values
}
else
{
    // Respond appropriately to the user cancelling the dialog
}

Its a good question - we're supposed to question stuff like this - but for me the current pattern is a decent one.

Murph

Answer 5

For modal input dialogs, I typically overload ShowDialog and pass out params for the data I need.

DialogResult ShowDialog(out datetime birthday)

I generally find that it's easier to discover and understand vs mixing my properties with the 100+ that the Form class exposes.

For forms, I normally have a Controller and a IView interface that uses readonly properties to pass data.