controles creando en un no-UI hilo

Question

I tienen una especie de modelo de plug-in en el que los diversos controles de usuario complejas se almacenan en archivos DLL y cargado y instanciados en tiempo de ejecución utilizando

Activator.CreateInstanceFrom(dllpath, classname). 

Desde que estoy loading bastantes de estos quería hacerlo en segundo plano, manteniendo mi IU sensible, creando un nuevo hilo para hacer la carga. Los controles se emparejan al formulario principal y se muestran cuando es necesario.

Parece que funciona bien, hasta que intento establecer cualquier propiedad en cualquier control anidado en uno de estos controles de usuario, p. Ej. en el controlador de eventos de un botón, que arroja una excepción de cruce cruzado. Me doy cuenta de que puedo evitar esto marcando InvokeRequired cada vez que accedo a una propiedad, pero prefiero no tener que preocuparme por eso al escribir el código para los controles de usuario (especialmente porque hay otros que también escriben estos bits de código que podrían no siempre recordar).

Así que mi pregunta es, ¿hay alguna manera segura de hacer lo que estoy intentando, o cómo debo cargar estos controles en segundo plano? ¿O es básicamente imposible y tengo que seguir el hilo principal para crear controles?

Espero que la información que he proporcionado sea suficiente para aclarar mi situación; si no, me complacería elaborar y proporcionar ejemplos de código.

Answer 1

Está bien cargar los archivos DLL y crear los objetos de control en segundo plano, pero el control debe agregarse al formulario en el hilo principal y toda la interacción del usuario, así como cualquier cambio programático de propiedades de control (después de que creado) tiene que ocurrir en el hilo principal. Simplemente no hay forma de evitar esto, ya que probablemente ya lo sepas. Ahora, a menos que la carga de esos archivos DLL y la creación de controles requiera años, no veo ninguna razón para hacerlo en hilos de fondo separados.

Si ciertas acciones realizadas por los controles están bloqueando la IU y desea que ocurran en segundo plano, esta es una historia diferente, y es mejor que considere cada acción de forma individual y cree métodos explícitos para comunicarse entre ellas y los hilos de fondo.

El intento de hacer uno genérico que sirva para todos marco que funciona de la misma en el modo de hilo de interfaz de usuario y en modo de fondo y simplemente comprueba los resultados InvokeRequired a veces en peor rendimiento (como todos los hilos se bloquean en la invocación) o incluso en interbloqueos (no detectados) tan pronto como la aplicación alcance una complejidad razonable. También realizar todas las actualizaciones asincrónicas en BeginInvoke, sin considerar cada método individualmente, puede dar como resultado problemas de consistencia de los datos (es decir, los controles pueden actualizarse a los estados atrás a tiempo debido a la inversión del orden de invocación entre subprocesos).

Answer 2

El ejemplo de código en this answer proporciona una forma elegante de solucionar este problema.

Código citado de esa respuesta:

public void UpdateTestBox(string newText) 
{ 
    BeginInvoke((MethodInvoker) delegate { 
     tb_output.Text = newText; 
    });   
} 

... aunque en su caso que se quiere llamar BeginInvoke en los propios controles:

public void UpdateTestBox(string newText) 
{ 
    tb_output.BeginInvoke((MethodInvoker) delegate { 
     tb_output.Text = newText; 
    });   
} 

Answer 3

No saber los detalles del mecanismo de InvokeRequired , He estado experimentando un poco y afaik puede establecer la mayoría de las propiedades en un subproceso, siempre y cuando no haya sido emparentado (es decir, agregado a alguna propiedad Control.Controles).

Así que debería poder preparar sus controles, almacenarlos en una lista y adjuntarlos a la interfaz de usuario principal en un método invocado.

---

Editar: No creo que importe qué hilo ha creado un Control. Por lo tanto, deberían aplicarse las reglas normales, es decir, solo puede trabajar con controles del hilo principal de Windows. Y creo que el criterio es HandleCreated en lugar de Parented. Mientras eso no haya sucedido, obtendrás un pequeño respiro.