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