Uso de nil

[CelestronFan]

Bueno, muchas gracias por la explicación tan detallada.

A ver si estoy en lo correcto, en conclusión nil, Assigned y Freeandnil se usan para corroborar si el objeto sobre el que se va a actuar está creado en memoria y en caso contrario actuar sobre la excepción que se generaría.

Entonces mi pregunta es, en lugar del nil ¿Se puede usar un bloque de este tipo?

 Try  
   sentencias... 
 Except 
   sentencias... 
 Finally o Raise 
   sentencias... 
 end

Es decir (usando el ejemplo de Lepe) podría hacer algo como esto?:

Código Delphi [-]
  private 
   nodo:TTreeNode;
 end;
 implementation
 
 // inicializamos el valor de nodo
 //procedure TForm1.Form1Create;
 //begin
 //  nodo := nil;
 //end;
 
 // accedemos al nodo o lo creamos si es necesario
 procedure TForm1.button1Click;
 begin
    Try
        nodo.text:= 'si ';
    Except
        nodo := TTreenode.Create(self);
        nodo.text:= 'si ';
  end;
 end;
 
 // al salir liberamos el nodo
 // si tienen nil no hace nada
 // si ha sido creado, lo libera
 
 procedure Tform1.FormClose;
 begin
   freeandnil(nodo);
 end;

La idea no es evitar manejar el nil, sino entender bien como hacerlo y saber si este tipo de casos se puede tratar como una excepción cualquiera.

Aunque me parece que no, porque haría lo indicado para cualquier tipo de excepción y no solo cuando el objeto no exista....

Si el control que estoy manejando pertenece a la forma principal de mi programa (me refiero a un control normal, que no se cree a posteriori en runtime) entonces no tendría sentido usar el nil, pues todos los controles de la forma se crean y asignan en memoria con Application.CreateForm(...
antes de que delphi ejecute Application.run,

...o ¿es que no he entendido que un control puede estar mostrado en una forma pero no asignado a memoria?

Gracias.

[dec]

Hola,

Empezado por CelestronFan

(...) en conclusión nil, Assigned y Freeandnil se usan para corroborar si el objeto sobre el que se va a actuar está creado en memoria y en caso contrario actuar sobre la excepción que se generaría.

Bueno. Yo diría que hay que matizar. "nil" puede usarse con los operadores de relación, tal como queda dicho más arriba. "Assigned" puede usarse en sentencias condicionales. "FreeAndNil" sirve para liberar un determinado objeto y hacer que la variable que guardara su referencia no apunte a ningún sitio en concreto. Pero no hay que actuar sobre excepción alguna, en mi opinión, puesto que lo siguiente no tiene porqué generar ninguna excepción.

Código Delphi [-]
 if Objeto <> nil then
   {...}
 else
   {...}

Empezado por CelestronFan

Entonces mi pregunta es, en lugar del nil ¿Se puede usar un bloque de este tipo?

 Try
   sentencias...
 Except
   sentencias...
 Finally o Raise
   sentencias...
 end

Creo que de lo de arriba lo que se ve extraño es el "Finaly o Raise". Pudiera ser que estuvieras refiriéndote a "Finally o Except".

Empezado por CelestronFan

Es decir (usando el ejemplo de Lepe) podría hacer algo como esto?:

Código Delphi [-]
 // accedemos al nodo o lo creamos si es necesario
 procedure TForm1.button1Click;
 begin
   Try
     nodo.text:= 'si ';
   Except
     nodo := TTreenode.Create(self);
     nodo.text:= 'si ';
   end;
 end;

No es del todo correcto, me parece a mí. Me explicaré. Se intenta asignar determinado valor a cierta propiedad del objeto "nodo": ya aquí, si no estás seguro de que "nodo" esté disponible deberías comprobar con un "if Assigned(nodo) then ..." o un "if nodo <> nil then ..." que esto es así. Si el objeto no estuviera disponible, tal como lo haces más arriba, evidentemente se produciría una excepción, que capturarías, y entonces crearías el objeto "nodo" y asignarías a su propiedad "Text" determinado valor... pero no creo que halla que llevar ahí, puesto que, como digo arriba, bastaría con comprobar si el objeto está creado o no lo está antes de asignar a su propiedad un determinado valor, o crearlo antes y hacerlo luego, si fuera menester.

Empezado por CelestronFan

La idea no es evitar manejar el nil, sino entender bien como hacerlo y saber si este tipo de casos se puede tratar como una excepción cualquiera.

Capturar la excepción que se produciría, efectivamente, podrías capturarla, creo yo, pero, ciertamente, creo que lo suyo es hacerlo como arriba se dice, mediante una sentencia condicional en donde se comprobara la disponibilidad del objeto en cuestión.

Empezado por CelestronFan

Aunque me parece que no, porque haría lo indicado para cualquier tipo de excepción y no solo cuando el objeto no exista....

Así es. Pero, además, insisto en que no veo la necesidad de hacerlo de ese modo, pudiéndose hacer como se dice arriba: creo que también se ganaría en legilibidad del código fuente. Y puede que hubiera otras razones por las que no sería recomendable hacer algo así. Se me ocurre que una vez entraras en la excepción... las siguientes instrucciones del procedimiento no se ejecutarían debidamente... aquí creo que me lío un poco y no sé explicarme o no lo tengo del todo claro. Te pido disculpas.

Empezado por CelestronFan

Si el control que estoy manejando pertenece a la forma principal de mi programa (me refiero a un control normal, que no se cree a posteriori en runtime) entonces no tendría sentido usar el nil, pues todos los controles de la forma se crean y asignan en memoria con Application.CreateForm(... antes de que delphi ejecute Application.run, ...o ¿es que no he entendido que un control puede estar mostrado en una forma pero no asignado a memoria?

No; has entendido bien, creo yo. Si tú no liberas un control que se muestra en una "forma" "desde su creación", este estará disponible y su referencia también lo estará. Si liberaras el control perderías su referencia y el mismo también dejaría de mostrarse en la "forma". Puedes probarlo. Sitúa dos botones en un formulario y, desde uno de ellos libera al otro: verás cómo desaparece el formulario.

[CelestronFan]

Gracias dec y a todos.

Quedó superclaro. Lo que más me cuesta del delphi es cambiar el modo de pensar durante la programación, y eso que me dediqué a hacer una flujograma para mi proyectito pero a pesar de eso me vuelvo un pastel con los objetos a veces. Bueno, con el tiempo y sus excelentes ayudas lo voy a superar....

Muchas Gracias.

[[Lepe]]

Resumiendo sería: "Mas vale prevenir que curar"

Como bien has dicho, la excepción tambien puede ocurrir por otra causa; asumir que se ha producido porque el objeto no esté creado, es demasiado

Empezado por CelestronFan

pues todos los controles de la forma se crean y asignan en memoria con Application.CreateForm(...
antes de que delphi ejecute Application.run,

El form Si se crea con Application.CreateForm, por tanto, pertenece a application y application se encargará de liberarlo.

Un TEdit, colocado en el form1, pertenece al Form, por tanto, al cerrar la aplicación:
- Application manda destruir a todos los Forms que contiene.
- Form1 manda a destruir todos los controles que contiene, entre ellos el Edit

De ahí que todos los objetos que son contenedores, TForm, Tpanel, etc, tengan la propiedad Components y ComponentsCount que es una lista de los controles que ha liberar ese objeto, y el orden en el que se crearon.