Llamar o no a Application.Run

[[Crandel]]

Pues si creo que voy a usar la segunda opción, la verdad es que dejemoslé el control a TApplicaction que para algo esta

Mi idea de no usarla venia por el lado que si no quería mostrar el formulario no quería darle la posibilidad que lo cree sin permiso. Pero por lo que veo sólo lo crea cuando se ejecuta Application.CreateForm(TForm1, Form1); por mas que este en Auto-create en las opciones.

Por otro lado me conveció el AddExitProc(DoneApplication);, que entre otras cosas se encarga de liberar la memoria de todos los componentes al terminar la aplicación.

Por el resto del comportamiento parece que es igual, hasta donde llegue a ver.

cada día se aprende un poco más sobre Delphi, que lindo que es esto.

Saludos y hasta el próximo mensaje de la vuelta

[roman]

Empezado por Crandel

Por otro lado me conveció el AddExitProc(DoneApplication);, que entre otras cosas se encarga de liberar la memoria de todos los componentes al terminar la aplicación.

¿Cuáles componentes?

Haciendo de abogado del diablo, las únicas componentes son las del formulario y éste es quien se encarga de destruirlas llamando su propio DestroyComponents.

Esto es, ¿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.

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.

Y colateralmente llama la atención algo, hablando de estándares que ni la propia Borland sigue, según la ayuda de Delphi:

AddExitProc adds Proc to the Delphi exit procedure list, so that Proc is automatically executed when the application terminates. AddExitProc is not compatible with CLX package support and is provided for backward compatibility only. Do not use AddExitProc in new applications.

Pues ¡vaya!, si no es que la usemos, es que estamos obligados a usarla en ¡¡cada aplicación!!

// Saludos

[[Crandel]]

Tambien es cierto que una instancia de la clase TApplication parece siempre existir por más que no se vea donde se hace.

Invirtiendo la idea, cual sería la ventaja de no usarla? habria realmente aprovechamiento de recursos u otra cosa?

Por el tema de memoria RAM consumida, parace ser igual en una prueba que recien hice.

[roman]

Empezado por Crandel

Tambien es cierto que una instancia de la clase TApplication parece siempre existir por más que no se vea donde se hace.

Difícilmente puedes deshacerte del objeto Application. Se crea en la inicialización de la unidad Controls y a menos que se quiera programar sin la VCL, el objeto siempre existirá.

// Saludos

[[Al González]]

¡Hola a todos!

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).

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.

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.