Orden de inicialización de las unidades Delphi:
1. System.pas
2. Windows.pas
3. SysUtils.pas
4. VarUtils.pas
5. Variants.pas
6. TypInfo.pas
7. Classes.pas
8. IniFiles.pas
9. Registry.pas
10. Graphics.pas
11. MultiMon.pas
12. UxTheme.pas
13. Themes.pas
14. DwmApi.pas
15. Controls.pas (Aquí es donde se crea el objeto Application )
16. ActnList.pas
17. Menus.pas
18. HelpIntfs.pas
19. Printers.pas
20. FlatSB.pas
21. GraphUtil.pas
22. ExtCtrls.pas
23. Dialogs.pas
24. Clipbrd.pas
25. Forms.pas
Si se elimina la creación del formulario principal en el dpr del programa y se elimina la clausula Uses Forms; las unidades inicializadas son las siguientes:
1. System.pas
En ocasiones nos encontramos que al redimensionar un formulario Delphi los controles parpadean... vamos a ver por que y como evitarlo.
Los controles Delphi descendientes de la clase TWinControl como TForm cuando reciben el mensaje de pintado WM_PAINT este es procesado por el metodo TWincontrol.WMPaint. La definición del metodo es ...
TWinControl.WMPaint(var Message: TWMPaint);
Si observamos el código fuente del metodo que se encuentra en la unidad Controls.pas observaremos que independientemente del tema del doble buffer básicamente lo que se hace es llamar al metodo PaintHandler cuya definición es...
procedure TWinControl.PaintHandler(var Message: TWMPaint);
Este metodo es el encargado de dibujar el contenido de nuestra ventana o control.
Es en este metodo donde empezamos a ver el problema. Veamos...
Lo primero que se hace en este metodo es llamar a la función WinApi BeginPaint. Pues bien, antes de que nuestro programa continué en la siguiente línea la ejecución de BeginPaint mandará al procedimiento de nuestra ventana directamente un mensaje WM_ERASEBKGND que sera tratada por el metodo WMEraseBkgnd cuya definición es ...
procedure TWinControl.WMEraseBkgnd(var Message: TWMEraseBkgnd);
dentro de este metodo se rellena el fondo de toda la ventana con el color de fondo definido para el control.
Es aquí precisamente donde notaremos el parpadeo ya que aun no hemos dibujado nada en nuestra ventana y esta ya ha sido borrada completamente solomente por haber llamado a la función WinApi BeginPaint.
Continuará...
El mensaje WM_PAINT es quizás el más difícil de comprender en su totalidad. Y esto es un problema ya que de él depende que nuestros programas funcionen de una manera fluida y elegante. Uno de las consecuencias más comunes de no procesar correctamente este mensaje es el parpadeo que producen los controles de un formulario o ventana cuando esta se está redimensionando con el ratón. Otro efecto también común es ver como zonas de las ventanas de nuestros programas no se redibujan correctamente cuando son tapadas por otras ventanas. ¿ Por qué nuestra aplicación recibe mensajes WM_PAINT ? Básicamente porque la filosofía de programación para Windows radica en el concepto de "No me llame, ya le llamare yo." o lo que es lo mismo... Que en la mayoría de las ocasiones será Windows quien le indique a nuestro programa que debe dibujar el contenido gráfico de sus ventanas. Obviamente también podemos forzar nosotros mismo el dibujado cuando sea necesario pero lo más habitual sea que el mismo Windows nos indique que debemos actualizar nuestra pantalla bien porque otra se haya colocado encima o por que se activado el salvapantallas o porque hemos maximizado o minimizado nuestra aplicación. Sea como sea tenga por seguro que Windows tarde o temprano nos va a mandar el mensaje WM_PAINT a nuestro programa. ¿ Dónde recibe nuestra aplicación los mensajes WM_PAINT ? Los mensajes WM_PAINT pueden llegar a nuestra aplicación solamente a tres sitios. O llegan a la cola de mensajes principal del programa, o la cola de mensaje de un thread que haya creado una ventana o directamente al procedimiento de ventana de una ventana. Pero vengan como vengan en realidad solo hay un sitio donde deberemos ocuparnos de ellos, que es en el procedimiento de ventana. ¿ Cuándo recibe nuestra aplicación mensajes WM_PAINT ?
Etiquetas: Conceptos, Mensajes WinApi
Suscribirse a:
Entradas (Atom)