.net - tutorial - ¿Por qué usar una ventana de propietario en MessageBox.Show?

winforms c# (8)

Configurar al propietario hace que el propietario se deshabilite mientras el cuadro de mensaje está abierto.

Si no configura el propietario, entonces el usuario puede hacer clic en otra cosa o incluso cerrar el propietario mientras está abierto el cuadro de mensaje, luego cuando se cierra el cuadro de mensaje y el código después de la llamada a MessageBox.Show se ejecuta su programa puede estar en una estado desconocido - o si el propietario se cerró, ahora está ejecutando código dentro de una ventana que ya no existe y cualquier llamada a métodos de WinForms o WPF (o para el caso también WinAPI y cualquier otro marco) es probable que cause un bloqueo.

MessageBox.Show tiene formularios como MessageBox.Show (ownerWindow, ....).

¿Qué gano al asignar una ventana de propietario?

Resulta que la propiedad de la ventana no es transitiva. En el caso donde tiene formulario, generando un formulario, generando un MessageBox, The MessageBox.Show necesita usar el parámetro ownerWindow. El formulario original debe establecerse como la ventana del propietario del MessageBox.

Usando Net Reflector, acabo de encontrar este código en Messagebox.Show:

else if (owner == IntPtr.Zero) owner = UnsafeNativeMethods.GetActiveWindow();

Por lo tanto, si no anida la propiedad (ventana - (posee) -> ventana - (posee) -> cuadro de mensaje), dejando de lado la ventana propietario establece el propietario que normalmente elegiría.

si no estoy equivocado, esto impide que la ventana del propietario se enfoque () hasta que se cierre el cuadro de mensaje.

Un cuadro de mensaje es un formulario modal, lo que significa que su ventana principal está deshabilitada hasta que se descarta el cuadro de mensaje.

Si se llama a una sobrecarga Show () que no toma un identificador de propietario, entonces un formulario principal generalmente se elige automáticamente. No encuentro nada en la documentación que describa cómo se elige ese formulario, pero mi experiencia es que si el cuadro de mensaje se muestra dentro del hilo de la GUI (es decir, el hilo principal o el hilo de la bomba de mensajes), entonces la ventana activa para ese hilo se elige como el padre.

Otros hilos pueden crear cuadros de mensaje sin forma primaria. Esta podría ser una mala situación, ya que podría situarse detrás de la ventana activa y el usuario ni siquiera sabrá que está allí hasta que cierre el programa. Para evitar esto, puede pasar el control de la ventana principal de la aplicación al método Mostrar, que deshabilitará esa ventana mientras dure el cuadro de mensaje.

AGREGADO: He estado pensando en esto y ahora no estoy tan seguro. El fragmento del reflector que proporcionó a continuación me hace pensar que tal vez el hilo no importe. (¡Dije que no pude encontrar nada en la documentación!)

Tendría que volver atrás y mirar el código para estar seguro, pero creo que los cuadros de mensaje que solía perder detrás del formulario principal pueden haber sido realmente formularios de mensaje personalizados, en cuyo caso mi experiencia es incorrecta, y tú nunca más tiene que proporcionar un parámetro de formulario principal.

Perdón por la confusion.

Mi recomendación ahora es nunca proporcionar este parámetro a menos que necesite algo más que la ventana activa para ser el formulario principal.

La documentación parece implicar que el único propósito del parámetro owner es si especifica MB_HELP, el cuadro de mensaje sabe a qué ventana debe enviar el mensaje WM_HELP.

http://msdn.microsoft.com/en-us/library/ms645505%28VS.85%29.aspx

Oh, me acabo de dar cuenta de que el OP era sobre .net - Di una respuesta sobre winapi - ¡lo siento!

Llamar a MessageBox.Show(frmMain,"a message","a title") agrega el formulario TextDialog a la colección de formularios Application.OpenForms() la Application.OpenForms() , junto con el formulario principal de frmMain. Permanece después de cerrar el Messagebox.

Acabo de descubrir 14 de estos cuando llamé a btnOK_Click() y establecí un punto de interrupción.

Cuando llamé a frmMain.Close() para cerrar el formulario principal, no pasó nada. frmMain no se cerrará hasta que los 14 Application.OpenForms también estén cerrados o, de lo contrario, deberá llamar a Application.Exit() .

Según las pruebas y esta otra respuesta , .net elegirá automáticamente la ventana enfocada actualmente en el mismo hilo que su llamada MessageBox.Show() . Para obtener el comportamiento correcto, debe asegurarse de mostrar el MessageBox desde el mismo hilo que esta ventana y especificar la ventana con la que el MessageBox está lógicamente asociado como owner . Un MessageBox solo modalmente bloquea la entrada a otros Form en el hilo desde el cual se lanza. Esto probablemente se relaciona con la forma en que MessageBox hace modal (¿tal vez intercepta mensajes dirigidos al hilo actual y solo permite que algunos mensajes pasen a ventanas que no sean ella misma?). El efecto de la entrada de bloqueo modal es que el usuario no podrá enfocar estas ventanas o cualquier control dentro de ellas e intentar hacerlo produce el sonido "Ding". Además, si no se especifica el propietario, MessageBox seleccionará automáticamente la ventana activa en el hilo actual. Si la ventana actualmente activa proviene de un hilo diferente (¡o de una aplicación diferente!), MessageBox no tendrá propietario. Eso significa que obtiene su propia entrada en la barra de tareas: se comporta como su propia ventana distintiva. El usuario puede subir otras ventanas en su aplicación (incluso si el usuario no puede interactuar con ellas). Puede obtener la situación en la que su programa deja de responder a la entrada del usuario con el usuario confundido porque el usuario de alguna manera levantó la ventana principal de la aplicación después de que se mostrara el cuadro de diálogo. Sin embargo, si el propietario está configurado correctamente, intentar subir la ventana principal hará que el MessageBox se eleve y parpadee.

Para que todo esto funcione bien con las ventanas secundarias, asegúrese de que cada ventana secundaria tenga su propiedad Owner establecida. Esto sucederá automáticamente si llama a ShowDialog() (que hace que su Form personalizado sea modal (y pase su parámetro de owner en los mismos casos donde pasaría el owner a MessageBox.Show() )).

Ahora, la mayoría de las formas de codificación de win consiste en escribir el código directamente en los manejadores de eventos dentro de una subclase de Form . Al escribir manejadores de eventos winforms, puede asumir muchas cosas. Primero, nunca debería tener una llamada a esto. this.Invoke() como una declaración de nivel superior en un manejador de eventos GUI porque dichos manejadores siempre se ejecutan en el mismo subproceso en el que se creó la subclase Form . En segundo lugar, para muchos (pero no todos) de estos manejadores, puede suponer que el Form tiene foco (y sería así elegido automáticamente por MessageBox.Show() como su propietario). Por ejemplo, al escribir código dentro del controlador de eventos Click de un botón (posiblemente llamado button1_Click ), puede suponer con seguridad que el formulario está enfocado (porque llamar a PerformClick() en el Button otro formulario es una mala práctica). Sin embargo, un Timer.Tick puede suceder incluso cuando su formulario no está enfocado. Entonces, en el caso de Timer.Tick , no hay necesidad de Invoke() (al igual que cualquier otro controlador de eventos de winforms), pero es necesario especificar el owner . Este último caso es más difícil de notar porque el desarrollador debe tener su aplicación desenfocada para darse cuenta de que un diálogo que se muestra en este caso se comporta de forma ligeramente diferente a cuando se enfoca su aplicación. Por lo tanto, especifique el owner cada vez que necesite usar Invoke() o si es posible que el evento se active cuando la ventana no está enfocada. Esta guía se aplica cuando se llama a MessageBox.Show() y Form.ShowDialog() .

La mayor parte de lo que analizo aquí es el resultado de perder el tiempo leyendo las otras respuestas.