Verificar existencia de TImage

[Tiaguito_Power]

Hola, muy buenas tardes a todos, les comento que estoy con Delphi XE y programando un juego de autos, quizas algunos lo recuerden de los 90, era unca caja cuadrada con un visor de acrilico con un autito fijo que se movia hacia los costados con un volantecito, y los obstaculos estaban pegados a un rodillo que funcionaba a cuerda, cuando le dabas cuerda el rodillo giraba y emulaba el movimiento del autito digamos. Bueno estoy haciendo basicamente eso, la cosa es asi, hay varios TImage, uno hace de fondo, otros las lineas blancas de la calle que se mueven, 2 autos fijos con movimiento lateral y dinamicamente un array de 250 imagenes que se van creando conforme pasa el tiempo en un TTimer. El proceso es el siguiente, al crear una imagen a la que considero trafico y esta choca con alguno de los dos autitos debería desaparecer, hasta ahi bien logro hacer que desaparezca, esta se suma a una variable global del form y va mostrando en un label cuando colisiona y en otro cuantos va esquivando. El trafico (array de imagenes) se crean en un ttimer cada 750 ms e incrementa una variable "CantidadTrafico" que se usa como referencia del array de images, estas van "avanzando" con un ttimer que ejecuta un bucle y dentro de el ejecuta "Trafico[i].Top:=Trafico[i].Top+1" siendo i equivalente a la variable "TraficoEliminado" que se enincrementa en uno cuando un autito fijo colisiona o lo esquiva.. Hasta aqui barbaro, al momento de verificar la colision hace "If (Trafico[x].Top + 66{alto del trafico}>= iAutito.Top) and (Trafico[x].Top<= iAutito.Top+44{alto del autito}) then" para saber si esta a la altura del choque y luego verifica en lugar del Top el paarmetro Left, si los valores del trafico estan dentro de los valores del autito este hace un Trafico[i].Free y elimina el TImage. Lo que necesito saber es como verificar a que componente del array se le hizo el Free ya que si el autito colisiona con algun trafico este debe validarse ya que el for que ejecuta el movimiento del trafico no lo sabe y cuando quiere acceder a un objeto eliminado me tira error.

Una cosa que probe pero que no funciono es el "if Trafico[i]=nil then exit".
Bueno, si alguno me puede dar una idea será bien recibida. Adjunto el .pas para que lo vean! y tambien parte del codigo debajo.


Creador de Imagen de trafico inicial y timer que mueve el trafico

Código Delphi [-]
procedure TfCoordinacion.btnCrearObjetosClick(Sender: TObject);
begin
CrearTrafico(CantidadTrafico,der);
Trafico[CantidadTrafico].Parent:=Self;
CantidadTrafico:=CantidadTrafico+1;
VelTrafico:= TTimer.Create(nil);
with VelTrafico do
begin
VelTrafico.Interval:=1;
VelTrafico.Enabled:=False;
OnTimer := VelTraficoTimer;
end;
VelTrafico.Enabled:=True;
tCreadorTrafico.Enabled:=True;
end;

Esto mueve el trafico creado y verifica si el top y el left del trafico esta dentro del autito y elimina el componente (esto no funciona bien :( )

Código Delphi [-]
procedure TfCoordinacion.VelTraficoTimer(Sender: TObject);
var i: integer;
begin
for i := TraficoEliminado to CantidadTrafico-1 do
  begin
   if Trafico[i]=nil then
      exit
  else
    Begin
   Trafico[i].Top:=Trafico[i].Top+1;
      Begin
    if ((Trafico[i].Top + 66>=iAutito.Top) and (Trafico[i].Top <= iAutito.Top+44)) or ((Trafico[i].Top + 66>=iAutito2.Top) and (Trafico[i].Top <= iAutito2.Top+44)) then
        if Trafico[i].Left + 44 in [iAutito.Left..(iAutito.Left+(iAutito.Height*2))] then
        Begin
          Trafico[i].Free;
          TraficoEliminado:=TraficoEliminado+1;
          Col:=Col+1;
          Label4.Caption:=IntToStr(col);
          exit;
        End;
      End;
    End;
   if Trafico[i].Top > (iAutito.Top + 50) then
    begin
     Trafico[i].Free;
     TraficoEliminado:=TraficoEliminado+1;
     Label1.Caption:=IntToStr(TraficoEliminado);
    end;
  end;
end;

[Casimiro Notevi]

No sé si podrás hacer esto:

Código Delphi [-]
Trafico[i].FreeAndNil;

En lugar de esto:

Código Delphi [-]
Trafico[i].Free;

[[AgustinOrtu]]

Yo desaconsejo el uso de FreeAndNil; ya ha habido varios debates en torno al tema

El problema que tenes es otro

Por que liberar la memoria de un objeto que vas a volver a usar?

Sobre todo si estas haciendo juegos, en donde como usas la memoria (o como no la aprovechas) se termina volviendo un problema

Ten en cuenta que la creacion de objetos es una operacion con costo, y hay objetos que son mas pesados que otros (TImage es uno de ellos)

Yo haria algo similar a esto:

Código Delphi [-]
uses
  Graphics;

type
  TTrafico = class
  strict private
    FImage: TImage;
    FChocado: Boolean;
  private
    procedure SetChocado(const Value: Boolean);
  public
    constructor Create;
    destructor Destroy; override;

    function VerificarChoque(const ATop, ALeft: Integer): Boolean;
    property Chocado: Boolean read FChocado write SetChocado;
    property Imagen: TImage read FImage;
  end;

implementation

{ TTrafico }

constructor TTrafico.Create;
begin
  inherited Create;
  FImage := TImage.Create;
  FChocado := False;
end;

destructor TTrafico.Destroy;
begin
  FImage.Free;
  inherited;
end;

procedure TTrafico.SetChocado(const Value: Boolean);
begin
  FChocado := Value;
end;

function TTrafico.VerificarChoque(const ATop, ALeft: Integer): Boolean;
begin
  Result := ...
end;

Ahora tendrias una clase propia en lugar de una imagen suelta, en la cual podes agegar un monton de informacion de estado, comportamiento, incluso eventos, etc

En lugar de un array de TImage, ahora tendrias un array of TTrafico

En cada elemento del array, tendrias una clase la cual contiene a su vez una imagen, accesible desde una propiedad, y una variable de bandera (Boolean) para saber si "esta chocado o no"

[Neftali [Germán.Estévez]]

Empezado por AgustinOrtu

El problema que tenes es otro
Por que liberar la memoria de un objeto que vas a volver a usar?

En eso estoy totalmente de acuerdo contigo Agustín, pero ese es otro problema.

Empezado por AgustinOrtu

Yo desaconsejo el uso de FreeAndNil; ya ha habido varios debates en torno al tema

Al contrario que el caso anterior, aquí no puedo estarlo.
¿Qué problema hay en utilizar FreeAnNil (o Free primero y luego asignar a NIL)?
¿Porqué lo desaconsejas (al contrario de lo que hago yo)?
¿Qué ventaja puede tener dejar la variable apuntando a "nosesabedonde" en lugar de apuntar a nil?

[[AgustinOrtu]]

Hay montones de hilos de "debate sobre religion" acerca de Free vs FreeAndNil

Por ejemplo Nick Hodges da algunas buenas razones para no usar FreeAndNil como una "receta magica que solucionara todos tus problemas"

Considera este ejemplo:

Código Delphi [-]
procedure TForm3.Button1Click(Sender: TObject);
begin
  // Query esta declarado en la seccion private
  if Query = NIL then // o bien, if not Assigned(Query)
  begin
    Query := TADOQuery.Create(NIL);
    Query.Connection := ADOConnection;
  end;

  try
    Query.SQL := '...' ;
    Query.Open;
  finally
    Query.Free;
  end;
end;

Obviamente falla, ya que como bien decis, al no haber asignado nil al puntero Query, si bien la memoria fue liberada, sigue apuntando a "quiensabedonde":

Query es distinto de NIL, entra en el bloque try-finally, y en la primer linea se rompe

No me gustaria proponer en ese caso "solucionarlo" con un FreeAndNil; porque si bien, el codigo va a funcionar, el problema es otro

1. Si se va a crear/destruir el query en cada ejecucion del metodo, porque esta declarado en la seccion private del Form? No seria mejor que este declarado local en el metodo? Mientras mas limitado el alcance de las variables, mejor

2. Si es necesario que este declarado como variable del Form porque se usa en otros metodos, porque hay que estar liberando la memoria en cada llamada al boton?

3. Osea que todo el codigo que use el objeto Query, va a tener que estar protegido con un chequeo contra NIL. Ahora bien, pregunto: Por que cuando se usa el TADOQuery soltando el componente en el Form no regamos el codigo con chequeos contra NIL?

No es mucho mas claro y sano ver esto?

Código Delphi [-]
constructor TForm3.Create(AOwner: TComponent);
begin
  inherited;
  ADOConnection := TADOConnection.Create(NIL);
  Query := TADOQuery.Create(NIL);
  Query.Connection := ADOConnection;
end;

destructor TForm3.Destroy;
begin
  ADOConnection.Free;
  Query.Free;
  inherited;
end;

procedure TForm3.Button1Click(Sender: TObject);
begin
  if Query.Active then
   Query.Close;

  Query.SQL := '...' ;
  Query.Open;
end;

[roman]

Me parece que estás mezclando peras con manzanas: estás criticando el uso de FreeAndNil poniendo un ejemplo en donde el menor de los problemas es la falta de uso de ese procedimiento. Por otra parte, esto (que tampoco viene mucho al caso)

Empezado por AgustinOrtu

Por que cuando se usa el TADOQuery soltando el componente en el Form no regamos el codigo con chequeos contra NIL

¿Por qué habríamos de hacerlo? Un componente insertado en tiempo de diseño en un formulario, jamás debe destruirse, de manera que sería absurdo checar si es nil. Además, eso de crear Queries por código, como no sea una especie de framework, es como mandar al traste el RAD de delphi. Mejor programamos en C

Más aún, si ese Query se va a destruir en el destructor del formulario, mejor lo creamos poniendo al formulario como owner y nos ahorramos llamar el Free. Claro que entonces, lo mismo habría sido insertar el componente

LineComment Saludos

[Neftali [Germán.Estévez]]

Es que lo que me estáis diciendo es algo así como:
..."Si usas FreeAndNil es que tu código está mal diseñado".
..."necesitas el FreeAndNil para que no pete".

No estoy de acuerdo.
El código estará bien o mal diseñado y se podrá usar o no FreeAndNil, pero no creo que tenga que ver lo uno con lo otro.

Habrá quien llene el código de variables globales, que no usará parámetros en los procedimientos y que duplicará decenas de líneas de código y al final usará FreeAndNil, y habrá quien lo diseñe correctamente y utilice Free.
Pero tal vez habrá quien haga lo segundo y utilice FreeAndNil (que es lo que intento hacer yo, por ejemplo).

Es una costumbre, a mi entender, de programación clara. Habrá quien lo considere innecesario, a mi me parece "ordenado".
Admito que es una cuestión de gustos, pero si las cosas están correctas, tan correcto es usarlo como no hacerlo.

NOTA: Ahora veo la respuesta de Román, y creo que más o menos es lo que intento explcar yo.

[[AgustinOrtu]]

Se suele decir que hay dos "escuelas", los que defienden el uso de FreeAndNil y los que no

Es una guerra que no va a tener fin nunca y en parte tenes razon German en que va en gustos

Vos decis que es mas ordenado y claro pero a mi me resulta mas desordenado y mas confuso

Cuando tiramos un query desde tiempo de diseño, no hay que andar haciendo chequeos para preguntar si puedo acceder al objeto o a sus propiedades (dejando de lado aquellas que hay que asignar desde afuera como Connection, etc) simplemente el objeto esta ahi, disponible en todo momento para mi; por algo esta declarado en la parte publica del form, tiene un alcance "global" dentro del form, y no limitado dentro de un metodo. A mi me resultaria muy extraño llegar a pensar que ese puntero pueda tener NIL

A mi no se me ocurre un solo caso en el que el uso de FreeAndNil sea necesario

Nunca ni siquiera me gusto la implementacion del metodo, mas que FreeAndNil deberia ser NilAndFree:

procedure FreeAndNil(var Obj);
var
Temp: TObject;
begin
Temp := TObject(Obj);
Pointer(Obj) := nil;
Temp.Free;
end;

[Casimiro Notevi]

Empezado por AgustinOrtu

procedure FreeAndNil(var Obj);
var
Temp: TObject;
begin
Temp := TObject(Obj);
Pointer(Obj) := nil;
Temp.Free;
end;

Como a todos los novatos, te recuerdo el uso de las etiquetas para el código

[Casimiro Notevi]

Yo suelo usar FreeAndNil donde creo que pueda ser útil.

Un puntero puede ser 'nil' o tener un valor. Pero si al hacer puntero.Free no lo deja a 'nil', entonces tenemos un problema. Imagina un array de punteros con una serie de valores/punteros que vas liberando y tienes que comprobarlo de alguna forma, la única es mirar si está a nulo/nil, pero si hacemos solamente .free estará liberado, pero no nos aseguran que tendrá un "valor nulo",

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

Como a todos los novatos, te recuerdo el uso de las etiquetas para el código

[roman]

Empezado por Casimiro Notevi

Yo suelo usar FreeAndNil donde creo que pueda ser útil.

Ni más ni menos El problema con visiones como las de Hodges, es que son extremistas. Él piensa que no debe usarse; ok, está en su derecho. Pero el problema es que piensa que quienes lo usan, lo usan para todo y en circunstancias totalmente reprobables donde, como dije, el menor de los problemas es su uso.

LineComment Saludos

[[AgustinOrtu]]

Empezado por Casimiro Notevi

Como a todos los novatos, te recuerdo el uso de las etiquetas para el código

Estas cosas nuevas que inventan estos dias

[Neftali [Germán.Estévez]]

Empezado por AgustinOrtu

Cuando tiramos un query desde tiempo de diseño, no hay que andar haciendo chequeos para preguntar si puedo acceder al objeto o a sus propiedades (dejando de lado aquellas que hay que asignar desde afuera como Connection, etc) simplemente el objeto esta ahi, disponible en todo momento para mi; por algo esta declarado en la parte publica del form, tiene un alcance "global" dentro del form, y no limitado dentro de un metodo. A mi me resultaria muy extraño llegar a pensar que ese puntero pueda tener NIL

Está claro que en ese punto no tiene sentido utilizar FreeAndNil, es más, es que en ese caso ni siquiera tendrás que usar un Free, pues no viene al caso.
Pero hay muchos otros objetos que se generan durante una ejecución y que se deben liberar.

Se me ocurre un ejemplo sencillo. ¿Has pasado alguna vez un objeto como parámetero en un procedimiento?
Mira este método, que viene del clubdelphi y que ahora mismo tengo en pantalla.

Código Delphi [-]
{: Devuelve una lista de nombres de fichero encontrados a partir de la
     carpeta inicial StartDir, que cumplen el patrón especificado por
     FileMask.Mediante recursively se indica si se desea hacer la busqueda
     en los subdirectorios.}
procedure FindFiles(StartDir, FileMask: string; recursively: boolean; var FilesList: TStringList);

Imagina que el último parámetro es opcional.
Se convertiría en:

Código Delphi [-]
{: Devuelve una lista de nombres de fichero encontrados a partir de la
     carpeta inicial StartDir, que cumplen el patrón especificado por
     FileMask.Mediante recursively se indica si se desea hacer la busqueda
     en los subdirectorios.}
procedure FindFiles(StartDir, FileMask: string; recursively: boolean; FilesList:TStringList=nil);

¿Has usado algo así alguna vez?
En este caso y según lo que hagas antes deberás asignar nil de forma obligatoria.

[Tiaguito_Power]

Muchachos, estoy muy agradecido por los aportes, la verdad no se me cruzo por la cabeza asignar Nil luego del Free

Empezado por AgustinOrtu
Por que liberar la memoria de un objeto que vas a volver a usar?

no es que estoy liberando o eliminando un componente que luego voy a volver a usar, el array de Images va de 0 a 250 y en tiempo de ejecución no se crean mas de 6 autitos trafico en simultaneo (del 0 al 5, 1 al 6, 2 al 7, etc), esto está dado por el "alto de la carretera" y una vez que nuestro autito paso y esquivó el trafico este se elimina y solo se tiene en cuenta el indice para que al ejecutar el bucle que desplaza las imagenes trafico omita el eliminado por colisión o sobrepaso.

Empezado por Neftali
¿Qué ventaja puede tener dejar la variable apuntando a "nosesabedonde" en lugar de apuntar a nil?

Si bien no me dedico 100% a programación adhiero a la idea de que una variable apunte a nil, ayuda a mantener orden y control sobre estas.

Desde ya agradezco todos los comentarios, aportes, ideas y debates. Aun no me he sentado a probar todo pero en cuanto lo haga les comento los resultados!

Cordiales saludos!!

[[AgustinOrtu]]

Cada uno programa como quiere

Aunque yo sigo sin entender porque tener 250 TImage cuando usas siempre 6 y no mas

Es como tener todos los forms creados apenas arranca el programa y no irlos creando y liberando a medida que es necesario

[mamcx]

Empezado por Tiaguito_Power

Si bien no me dedico 100% a programación adhiero a la idea de que una variable apunte a nil, ayuda a mantener orden y control sobre estas.

NIL/NULLs son valores ultraproblematicos, y se deberian evitar al maximo:

https://dzone.com/articles/the-worst...uter-science-1

Ademas, NIL no es muy diferente de apuntar a "donde sea". NIL no es un valor fijo, no significa nada concreto (que uno le suponga un significado es otra cosa). NIL no es vacio, ni *nada*, ni *algo*. NIL es "indefinido". NIL no es igual a NIL ni es diferente de NIL (Delphi dice que NIL=NIL, pero eso es un error!).

En fin...

-----

Entre los programadores de juegos, hay un esquema que es muy popular, porque es mas eficiente y ademas mas claro a la hora del codigo:

http://gamedevelopment.tutsplus.com/...ign--cms-21052

----

Sin embargo por la simplicidad de tu problema, hago eco de lo que te han dicho. Si ya tienes fijo el tamaño de tu problema, es mas simple que pre-cargues al arranque todo y simplemente reemplaces (en vez de crear/eliminar cada vez). Eso es truco de programacion pa' videojuegos #1 (y que es parte de lo que el link arriba te enseña).

[[AgustinOrtu]]

+1 Mario

Basicamente si uno programa como si nil nunca existiera, no deberia haber problemas; al menos no en la base de codigo escrita por el/los programadores del equipo

Código Delphi [-]
procedure FindFiles(StartDir, FileMask: string; recursively: boolean; FilesList:TStringList=nil);

Leyendo el comentario, "devuelve una lista de"... no seria mejor una function para el caso?

Y en el caso de, darle la lista al metodo para que ahi meta lo que va encontrado, es responsabilidad del usuario del metodo suministrar un StringList; basicamente, si no me lo dan, ocurrira la excepcion que tiene que ocurrir, y eso es solo culpa de quien invoca el metodo y no de quien lo programo

Pero como ya dijimos mas arriba, para gustos, colores

[roman]

Empezado por mamcx

NIL/NULLs son valores ultraproblematicos, y se deberian evitar al maximo:

Esto puede ser verdad, o, por lo menos, debatible. Pero lo que aquí hablamos es del uso de FreeAndNil, no de la existencia y uso de nil.

LineComment Saludos

[Casimiro Notevi]

Empezado por mamcx

(Delphi dice que NIL=NIL, pero eso es un error!).

Pues yo le creo, a Delphi
Y FreeAndNil es muy útil en diversas ocasiones.