FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Tiempo de proceso excesivo
Tengo la siguiente función que crea en tiempo de ejecución grupos de 7 componentes y le asigna propiedades y eventos , la llamo al crear el form n veces donde n varia entre 100 y 300... mi problema es que con un ordenador de última generación esta 9 o 10 segundos para crear los componentes y al trasladarlo a mi cliente sera inoperativo, ¿ se os ocurre porque tarda tanto ? creo que debería ser mucho mas rápido...
Otra cosa, al mover de sitio todos esos componentes veo como se van dibujando en pantalla grupo por grupo, y eso sin emplear la función processmesages ¿existe alguna manera de indicar al form que no se vea nada hasta que lo haya redibujado todo? Gracias anticipadas
|
#2
|
||||
|
||||
El problema es que los procedimientos de redibujado estarán ocupando todo el tiempo y además es exponencial a medida que vas incrementenado el número de componentes.
Lo primero que se me ocurre es que crees los componentes antes de visualizar el form. A ver si así evitas que se lancen procedimientos de pintado. ¿Dónde llamas actualmente a este procedimiento? ¿En el OnShow? ¿Después del OnShow? Otra opción es probar, por ejemplo a crearlos dentro de un frame o contenedor con este oculto, y una vez creados todos visualizarlos...
A ver si esto mejora el tiempo.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#3
|
|||
|
|||
Llamaba en el evento oncreate...
He probado lo que me dices, he puesto todo en un panel con visible false y en onshow panel.visible:=true... hasta llegar a la linea panel.visible:=true ha sido inmediato y al ejecutar la linea dicha hace exactamente lo mismo que antes de modificar nada!!!, luego es evidente que es el dibujado y no la creación. habria que encontrar la manera que solo lo dibujara una vez al final y no componente por componente pero no se me ocurre nada aparte de lo que ya hemos probado ¿alguna idea? Gracias |
#4
|
||||
|
||||
Lo siguiente que se me ocurre es intentar acceder a los eventos WMPAINT de los componentes e intentar que no se lancen hasta que acabe la creación.
Algo así como el DisableControls de los componentes de Base de Datos. Habría que revisar la VCL y ver los mensajes que se están lanzando para pensar en alguna opción...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#5
|
||||
|
||||
No la he probado nunca, así que no te se decir si va a servir de algo, pero por probar que no quede.
Revisa información sobre la API LockWindowUpdate. Échale un vistazo también este mensaje de los foros de EMB.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#6
|
||||
|
||||
Tener un formulario con demasiados controles es un signo de mal diseño.
__________________
El malabarista. |
#7
|
|||
|
|||
Cita:
|
#8
|
|||
|
|||
Cita:
|
#9
|
|||
|
|||
No lo dudo pero el problema tiene su miga y la solución de componentes cumple con el resultado esperado excepto con el factor tiempo, resumiendo, hay que mostrar en pantalla todas las reservas de un mes de un hotel determinado y que se puedan mover arrastrando la reserva de un día a otro, todo va bien hasta que el hotel esta lleno... si se os ocurre otra forma estoy abierto a lo que sea, lo intentamos con varios tipos de grids pero nos fue imposible implementar toda las funcionalidad requerida.
Última edición por elguille fecha: 10-04-2013 a las 09:29:03. |
#10
|
|||
|
|||
Cita:
Saludos.. |
#11
|
||||
|
||||
Bueno, yo hace tiempo para cosas similares a esta utilicé el componente TSimpleGraph de DelphiArea.
Para que te hagas una idea, aquí puedes ver algunas imágenes y hacerte a la idea del número de objetos con los que se trabajaba. Cada objeto es independiente y tiene sus propiedades, se puede seleccionar, arrastrar,... Cambiar ahora todo el diseño puede ser complejo y costoso, pero al menos tienes una alternativa. Sería bueno, que utilizaras un Profiler, para ver dónde se está "perdiendo" ese tiempo exactamente.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#12
|
|||
|
|||
A juzgar por las imágenes podria intentar adaptarme aunque intentare primero acelerar todo lo que pueda a ver si basta...
Gracias por tu ayuda Neftali |
#13
|
||||
|
||||
Cita:
O con http://www.lischke-online.de/index.p...tual-treeview? El concepto en DevExpress/VirtualTree que mas aplica es el uso de una fuente de datos "virtual". En donde los datos (y controles) se trabajan bajo demanda, en vez de cargarse todo en un solo golpe (similar a hacer SELECT * FROM Tabla WHERE Filtro). Ahora que trabajo mucho con objective-c/iOS es un modelo muy bueno. Por otro lado, puede que te sirva manejar ciertas cosas no como controles, sino como imagenes dibujadas en tiempo ejecucion. Los controles nativos de windows cargan mas recursos, mientras que las imagenes no tanto.
__________________
El malabarista. |
#14
|
||||
|
||||
elguille,
Cita:
Cita:
Nelson. |
#15
|
|||
|
|||
Cita:
|
#16
|
|||
|
|||
De todas maneras afine el numero de componentes creados al minimo (no creo los que no se van a dibujar) y el tiempo bajó algo , lo suficiente para hacerlo soportable... doy por cerrado el hilo..
Gracias a todos por la ayuda |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Delphi 2007, consumo excesivo de cpu | Casimiro Notevi | La Taberna | 3 | 06-01-2010 00:23:36 |
consultas con excesivo tiempo de respuesta a una tabla | eddvedder | Conexión con bases de datos | 1 | 22-01-2009 21:35:25 |
excesivo uso de transacciones | macro32 | Conexión con bases de datos | 5 | 22-04-2008 10:25:41 |
Crecimiento excesivo | jsanchez | Firebird e Interbase | 21 | 08-03-2007 19:52:29 |
Excesivo consumo de memoria | 1111111 | Firebird e Interbase | 11 | 19-06-2005 00:08:20 |
|