Llamar o no a Application.Run

[Crandel] · #1 13-09-2005

Hola a todos de nuevo, estoy diseñando una aplicación que de acuerdo a la ciertos parámetros de entrada abre o no su formulario principal.
Para estoy programando directamente el archivo dpr, y después de analizar los parámetros de entrada decido abrir el formulario principal.
La duda se me plantea en si realmente es necesario llamar a Application.Run.
Los dos códigos que pelean el puesto son:

Código Delphi [-]  Application.Initialize;
  Application.Title := 'Clean code';

  if (ParamCount>0) then
  begin
     ....
  end;

  if ... then
  with TForm1.Create(nil) do
  begin
    ShowModal;
    Free;
  end;

y la opción 2:

Código Delphi [-]  Application.Initialize;
  Application.Title := 'Clean code';

  if (ParamCount>0) then
  begin
     ....
  end;

  if ... then
  begin
    Application.CreateForm(TForm1, Form1);
    Application.Run;
  end;

En el primer caso no tengo ningún formulario con auto-create y en el segundo solo el principal.

El comportamiento probado es igual, hasta donde vi. Son realmente equivalentes? Cual me conviene de los dos ???

roman · #2 13-09-2005

Buena pregunta. Tanto Application.Run como Form.ShowModal entran en un loop que va leyendo y procesando uno a uno los mensajes que llegan a la aplicación. En el primer caso el loop termina cuando la propiedad Application.Terminated es true y en el segundo cuando Form.ModalResult es distinto de cero.

Aparte de eso, Application.Run hace algún trabajo de mantenimiento como AddExitProc(DoneApplication) pero no sé hasta qué punto afecte.

A falta de una respuesta clara, yo usaría el segundo método pues, a fin de cuentas, el primer método podrías usarlo en cualquier aplicación... y por algo no se usa así.

No es una respuesta pero, como te digo, a falta de algo claro...

// Saludos

dec · #3 13-09-2005

Hola,

Lo cierto es que no tengo razones suficientes como para hacerte decidir sobre una forma u otra de actuación, pero, me da en la nariz que es más pertinente utilizar el "Application.Run" en lugar de "ShowModal". ¿En qué me baso para decir esto? Básicamente en la codificación del método "Run", de la clase "TApplication", en comparación con el método "ShowModal", de la clase "TCustomForm".

Si miras cómo están codificados ambos métodos, puede que los resultados que ofrezcan sean parecidos, pero, para mí tengo que no iguales, que, aunque los resultados sean iguales, aparentemente, se hacen cosas distintas en ambos lugares y acaso alguien más experimentado pudiera decir en qué cosas, exactamente, difieren ambos métodos.

En los dos ("Run" y "ShowModal") se entra en un bucle "repeat .. until", pero, desde luego, a simple vista parece mucho más pesado el uno que el otro: parece, repito, más liviano el bucle de "Run" que el bucle de "ShowModal". Parece incluso como si en el método "ShowModal" de "CustomTForm" se tuviera en cuenta la posibilidad de iniciarse con un formulario "modal", puesto que se llama al método "Application.ModalStarted" en su interior.

En fin, no sé Crandel, pero, me da en la nariz que lo que uno pretende iniciar es una aplicación, no un formulario, únicamente, y así se debería llamar al método "Run" de "TApplication", en lugar de al "ShowModal" de "TCustomForm". De todos modos, como no doy razones suficientes (en realidad únicamente conjeturas) el tema parece interesante y tal vez alguien nos ofrezca un poco más de información sobre este asunto.

En fin -termino con esto- pareciera que el mostrar un formulario "modalmente" es una especie de excepción a la regla, quiere decirse, normalmente los formularios no se muestran así: son los cuadros de diálogo los que se muestran de este modo, que, de acuerdo, pueden ser bastantes, pero no deja de ser una excepción a la regla esta que acabo de inventarme. De hecho tienes que empezar mostrando el formulario "modalmente" y así aprovecharte del "bucle" que he mencionado, porque si mostraras el formulario con el método "Show" el programa terminaría acto seguido, al no aprovecharse del "bucle" en el interior del método "Run" de "TApplication".

Vale. Para no decir nada ya está bien lo dicho. A ver qué puede sacarse en claro de todo esto

[Crandel] · #4 14-09-2005

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 · #5 14-09-2005

Cita:

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:

Cita:

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] · #6 14-09-2005

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 · #7 14-09-2005

Cita:

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] · #8 09-10-2005

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