¡Hola a todos!
Cita:
|
Empezado por roman
¿Cuáles componentes?...las únicas componentes son las del formulario y éste es quien se encarga de destruirlas...¿cuándo o en qué aplicaciones hay componentes, que no sean los mismos formularios, cuyo dueño directo sea Application? Y en el caso de formularios... pues tú mismo lo estás destruyendo...
|
Hay casos donde se crea un componente en tiempo de ejecución haciendo que su dueño (Owner) sea el objeto Application. Esto pudiera ejecutarse, por ejemplo, desde algún evento de la forma mencionada o de uno de sus componentes.
Aunque, claro está, la destrucción de todos los componentes adueñados por el objeto Application, ocurrirá de todas maneras al destruir este objeto (lo cual se realiza automáticamente en la sección de finalización de la unidad Controls).
Cita:
|
Empezado por roman
...Posiblemente la razón sea que el método especificado en AddExitProc se ejecute aún cuando hay una excepción que obliga a la aplicación a cerrarse a la mala...
|
Sólo para aclarar, en la sentencia «AddExitProc(DoneApplication);» contenida en TApplication.Run,
DoneApplication no es un método sino un procedimiento que no pertenece a ninguna clase de objeto. Curiosamente, ese mismo procedimiento es llamado desde la sección de finalización de la unidad Forms (la de la clase TApplication).
Esto puede hacernos suponer que la sentencia «AddExitProc(DoneApplication);» en TApplication.Run es innecesaria. Inclusive, tal parece que DoneApplication se ejecuta dos veces si previamente hubo una llamada a TApplication.Run; la primera cuando, al terminar el programa, se llama al procedimiento ExitProc, y la segunda cuando posteriormente se ejecuta la sección de finalización de la unidad Forms. En la unidad System.pas se puede apreciar como _Halt0 llama primero al procedimiento ExitProc y posteriormente a FinalizeUnits, el procedimiento que ejecuta las secciones de finalización de cada unidad. El procedimiento _Halt0 es llamado siempre que un programa termina de forma controlada.
Por alguna razón Borland busca que el procedimiento DoneApplication sea ejecutado antes que el código de finalización de cualquier unidad, cuando hubo una llamada al método Run de TApplication.
Cabe señalar que AddExitProc permite crear fácilmente una cadena de varios procedimientos de salida asignada a la variable ExitProc, pero la correcta ejecución de esa cadena requiere de la
complicidad del procedimiento DoExitProc de la unidad SysUtils.pas y de un pequeño ciclo como el encontrado en el procedimiento _Halt0 de System.pas:
Código Delphi
[-]
while ExitProc <> nil do
begin
@P := ExitProc;
ExitProc := nil;
P;
end;
Se ve extraño, pero después de analizar lo que hace DoExitProc cobra sentido.
Cita:
|
Empezado por roman
...Do not use AddExitProc in new applications[ayuda de Delphi]. Pues ¡vaya!, si no es que la usemos, es que estamos obligados a usarla en ¡¡cada aplicación!!...
|
Creo que Borland colocó la leyenda «provided for backward compatibility» en los temas
ExitProc variable y
AddExitProc procedure de la ayuda de Delphi con la intención de que los programadores empiecen a desacostumbrar el uso del procedimiento ExitProc, quizá planeando una nueva forma de organizar el código de finalización de las aplicaciones en futuras versiones de Delphi. Pero eso no obliga a la propia Borland a prescindir de esos elementos, que por ahora siguen siéndole útiles según se ve.
Estas apreciaciones las hago en base al código fuente de las bibliotecas RTL y VCL de Delphi 7.
Un abrazo de salida.
Al González.
