¿Por qué se prefiere InvokeRequired sobre WindowsFormsSynchronizationContext?
En cualquier momento el principiante pregunta algo como: ¿Cómo actualizar la GUI desde otro hilo en C #?, la respuesta es bastante directa:
if (foo.InvokeRequired)
{
foo.BeginInvoke(...)
} else {
...
}
¿Pero es realmente bueno usarlo? Justo después de que el hilo no GUI ejecutafoo.InvokeRequired
el estado defoo
puede cambiar. Por ejemplo, si cerramos el formulario justo después defoo.InvokeRequired
, pero antesfoo.BeginInvoke
, llamando afoo.BeginInvoke
dará lugar aInvalidOperationException
: Invoke o BeginInvoke no se pueden invocar en un control hasta que se haya creado el identificador de ventana. Esto no sucedería si cerramos el formulario antes de llamar aInvokeRequired
, porque seríafalse
incluso cuando se llama desde un hilo no GUI.
Otro ejemplo: digamosfoo
es unTextBox
. Si cierra el formulario y luego se ejecuta ese subproceso no GUIfoo.InvokeRequired
(que es falso, porque el formulario está cerrado) yfoo.AppendText
conducirá aObjectDisposedException
.
Por el contrario, en mi opinión usandoWindowsFormsSynchronizationContext
es mucho más fácil: publicar devolución de llamada usandoPost
ocurrirá solo si el hilo todavía existe, y llamadas síncronas usandoSend
lanzaInvalidAsynchronousStateException
si el hilo ya no existe.
No está usandoWindowsFormsSynchronizationContext
simplemente más fácil? ¿Me estoy perdiendo de algo? ¿Por qué debería usar el patrón InvokeRequired-BeginInvoke si no es realmente seguro para subprocesos? ¿Qué piensas que es mejor