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
Tipos de las relaciones
- Herencia
Es la relación que se establece entre dos clases cuando una desciende de la otra. - Asociación
Es cuando en una clase usamos un objeto de otra clase para realizar una tarea en particular y creamos , usamos y destruimos el objeto de una manera local.
No se trata de relaciones fuertes entre objetos y suelen ser creadas en tiempo de ejecución.
Se representa mediante una línea continua. - Agregación
Suelen representar una relación Todo-Parte en la que el objeto contenedor contiene a otros objetos pero no ha sido la responsable de crearlos y tampoco tiene la responsabilidad de destruirlos.
El caso mas normal se da cuando un objeto hace referencia a otro mediante una propiedad ejerciendo esta solamente como una referencia al objeto. La propiedad sera asignada o desasignada en tiempo de ejecución.
Se representa con una linea que tiene un rombo blanco en el extremo correspondiente al objeto contenedor. - Composición
Es como una agregación pero mas fuerte. Es decir, los objetos contenidos serán creados y destruidos por el objeto contenedor. Solo existirán en tanto exista el objeto que los contiene.
Se representa por una línea que tiene un rombo negro en el extremo correspondiente al objeto contenedor. - Dependencia
- Realización
Cardinalidad de las relaciones
Según el número y origen y destino de las relaciones entre objetos tendremos los siguientes tipos de relaciones:
- Uno a Uno
- Uno a Muchos
- Muchos a Muchos
Suscribirse a:
Entradas (Atom)