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

Question

Así que ahora mismo mi proyecto tiene algunos diálogos personalizados que hacen cosas como avisarle al usuario por su cumpleaños, o lo que sea. En este momento solo están haciendo cosas como establecer una propiedad this.Birthday una vez que obtienen una respuesta (que es del tipo DateTime?, con el nulo que indica "Cancelar"). Luego, la persona que llama inspecciona la propiedad Birthday del cuadro de diálogo que creó para averiguar qué respondió el usuario.

Mi pregunta es, ¿hay un patrón más estándar para hacer cosas como esta? Sé que podemos configurar this.DialogResult para las funciones básicas de Aceptar/Cancelar, pero ¿hay alguna 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 diálogo personalizado es la manera idiomática de hacerlo porque así es como lo hacen los diálogos estándar (como el Select/OpenFileDialog). Alguien podría argumentar que es más explícito y la intención de revelar que tiene un método ShowBirthdayDialog() que arroja el resultado que está buscando, pero seguir el patrón del marco es probablemente la mejor manera de hacerlo.

Answer 2

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

Answer 3

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

No, parece que está utilizando el enfoque correcto.

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

Answer 4

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

Dos buenas razones Desde mi punto:

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

El flujo de la lógica también es muy 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 este tipo de cosas - pero para mí el patrón actual es una decente.

Murph

Answer 5

Para los cuadros de diálogo de entrada modales, normalmente sobrecargue ShowDialog y pase hacia fuera params para los datos que necesito.

DialogResult ShowDialog(out datetime birthday) 

por lo general encuentran que es más fácil de descubrir y comprender vs mezclar mis propiedades con las más de 100 que la clase Form expone.

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