multithreading - Creación de formas Delphi sin congelar el hilo principal

forms vcl

Question

Estoy teniendo problemas con algo que quiero hacer. Tengo algunas formas grandes que tardan en crearse. Para que la aplicación se cargue más rápido, pensé en permitir que los formularios se crearan en un hilo creado en el evento OnCreate del formulario principal. El hilo tiene un campo FApplication de tipo TApplication que obviamente es la variable Aplicación. Lo uso para crear los formularios en el hilo, pero aunque lo intenté

FApplication.CreateForm (TfrmXXX, frmXXX) 

y

frmXXX := TFrmXXX.Create(FApplication)

las formas aún no son creadas. ¿Hay alguna solución para esto?

Gracias por adelantado.

Answer 1

Como señala Riho, la creación de formas no debería tomar tiempo. Lo que puede llevar tiempo, sin embargo, es todo el código que coloca en el constructor o el evento OnCreate de ese formulario.

Perfile su código, como sugirió Craig, para que sepa qué código ocupa la mayor parte del tiempo. Luego vea si puede mover parte de ese código en un hilo separado.

Answer 2

Crear formularios en un hilo simplemente no funcionará. El VCL, y especialmente la parte visual, no es seguro para subprocesos. Renuncia a esa idea, y en su lugar optimiza el código que está causando que el formulario tarde mucho tiempo en crearse. No nos has dicho cuál es la parte lenta. Si puede responder eso, tal vez podamos sugerir un método para acelerarlo.

En general, no es posible hacer un buen trabajo mejorando el rendimiento de un código hasta que lo haya perfilado y sepa exactamente cuál es el problema. De lo contrario, solo estás perdiendo el tiempo.

Answer 3

La solución no será fácil, ya que

1. Delphi VCL no es seguro para subprocesos
2. la creación de ventanas en otro subproceso requiere que el subproceso respectivo tenga un bucle de mensaje

¿Necesitas todos los formularios a la vez? De lo contrario, podría diferir la creación a un tiempo donde la aplicación está inactiva (es decir, TApplicationEvents.OnIdle). O solo muestra una bonita barra de progreso :)

Answer 4

No puedo imaginar lo que tomaría tanto tiempo en la creación de formas que necesitaría hilos para resolver. Si se trata de una gran cantidad de datos, intente limitar la cantidad que se muestra inicialmente.

Answer 5

Como se indicó anteriormente, debe crear los formularios en el hilo VCL. PERO, no necesitas hacer todo allí:

Si sus formularios tienen muchos datos de imágenes, puede eliminarlos de los formularios y colocarlos en un archivo de recursos (o simplemente usar archivos de imágenes sin formato).

En el constructor de su formulario, inicie un hilo de fondo para leer los datos de imagen de los recursos y hacer otras cosas lentas. Anule su evento OnShow de formularios para asegurarse de que espera a que se complete el subproceso en segundo plano antes de que se muestre el formulario.

Answer 6

Este es un atajo que hemos usado anteriormente para formularios que tienen mucho proceso por hacer en la creación. Coloque un TTimer en el formulario y configúrelo en falso. OnCreate del formulario habilítalo. Luego coloque todo el código que tenía en OnCreate en el evento OnTimer. Establecer el intervalo entre 250 y 500 es suficiente.

Esta no es una solución elegante, pero es simple.

Answer 7

hay algunas formas grandes por ahí como dije antes. el archivo DFM es como 3mb (incluidos los datos de imagen, por supuesto). De hecho, creo que la mayor parte del tiempo de creación se debe a eso en lugar del código ejecutado. Pero quizás dividirlos y crearlos cuando la aplicación está inactiva, el tiempo de carga actual no es realmente grande (como 4 o 5 segundos) pero lo investigaré. gracias por tus respuestas

Answer 8

Simplemente coloque un PostMessage en los formularios OnCreate, y escriba un procedimiento en el formulario para manejar el postmensaje. De esta forma, todo el código que lleva tiempo puede eliminarse del método OnCreate. Sin embargo, sí estoy de acuerdo, solo crea el formulario cuando sea necesario, y luego implemente un poco de lógica para decidir si va a liberarlo de cerca, o no. Dependiendo del tiempo de carga y la posibilidad de que el usuario lo quiera de nuevo.

Jens Fudge, Archersoft