¿Existe una forma estándar de devolver valores de cuadros de diálogo personalizados en Windows Forms?

Question

Ahora mismo mi proyecto tiene algunos cuadros de diálogo personalizados que hacen cosas como indicarle al usuario su cumpleaños o lo que sea.Ahora mismo sólo están haciendo cosas como establecer un this.Birthday propiedad una vez que obtienen una respuesta (que es del tipo DateTime?, donde el valor nulo indica "Cancelar").Luego la persona que llama inspecciona el Birthday propiedad del cuadro de diálogo que creó para averiguar qué respondió el usuario.

Mi pregunta es, ¿Existe un patrón más estándar para hacer cosas como esta? Sé que podemos configurar this.DialogResult para cosas básicas de Aceptar/Cancelar, pero ¿hay una forma más general en Windows Forms para que un formulario indique "aquí están los datos que recopilé"?

Answer 1

Yo diría que exponer propiedades en su cuadro de diálogo personalizado es la forma idiomática de hacerlo porque así es como lo hacen los cuadros de diálogo estándar (como Select/OpenFileDialog).Alguien podría argumentar que es más explícito y revelador de intenciones tener un método ShowBirthdayDialog() que devuelva el resultado que estás buscando, pero seguir el patrón del marco es probablemente el camino más inteligente a seguir.

Answer 2

¿Existe un patrón más estándar para hacer cosas como esta?

No, parece que estás utilizando el enfoque correcto.

Si el cuadro de diálogo devuelve DialogResult.OK, suponga que todas las propiedades necesarias en el cuadro de diálogo son válidas.

Answer 3

Para mí, seguir con el cuadro de diálogo que devuelve las respuestas del cuadro de diálogo estándar y luego acceder a los resultados a través de las propiedades es el camino a seguir.

Dos buenas razones desde mi punto de vista:

1. Coherencia: siempre estás haciendo lo mismo con un diálogo y la naturaleza misma de la pregunta sugiere que los patrones son buenos (-:Aunque igualmente la pregunta es si este es un buen patrón.
2. Permite la devolución de múltiples valores desde el diálogo. Bueno, aquí también hay una discusión completamente nueva, pero el pragmatismo aplicado significa que esto es lo que uno quiere, en algunas circunstancias no siempre es apropiado o deseable empaquetar valores solo para poder volver a pasarlos. todo de una vez.

El flujo de lógica también es bueno:

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

Es una buena pregunta (se supone que debemos cuestionar cosas como esta), pero para mí el patrón actual es decente.

Murph

Answer 4

Para los cuadros de diálogo de entrada modales, normalmente sobrecargo ShowDialog y paso parámetros para los datos que necesito.

DialogResult ShowDialog(out datetime birthday)

Generalmente encuentro que es más fácil de descubrir y comprender que mezclar mis propiedades con las más de 100 que expone la clase Form.

Para los formularios, normalmente tengo un controlador y una interfaz IView que usa propiedades de solo lectura para pasar datos.

Answer 5

Siempre lo he hecho exactamente como lo estás describiendo.Tengo curiosidad por ver si hay un enfoque más aceptado.