Saber si se ha creado un objeto

[*Caro*]

Empezado por roman

Assigned es esencialmente lo mismo que la comparación con nil por lo que si falla uno también el otro. Es raro que falle porque siendo una variable global, tendría que inicializarse a nil. Sin embargo, veo que en el código que nos presenta Cecilio usa

ds.create(self)
lo cual es incorrecto para crear el objeto y quizá de ahí venga la falla. Tendría que ser así:



Código Delphi [-]
ds := TClientDataSet.create(self)

No me había fijado bien como estaba creando su ClientDataSet, ayer respondi rapido y me desconecte despues.

Como te dice el amiguito Roman no debería fallar ya que con el Assigned es como si estuvieras preguntando.

Código Delphi [-]
  if ClientDataSet<> nil then
   //esta creado

La creación de tu ClienDataSet tampoco esta correcta, debes hacerlo como te indica Roman y podrías hacer algo así.

Código Delphi [-]
 if Assigned(ClientDataSet) then
  ClientDataSet.Free; //Si esta creado liberamos

 ClientDataSet := TClientDataSet.Create(Self);

Tengo una pregunta yo pense que si no creabas el objeto apuntaba a nil no importando que sea una variable global o una local, acabo de hacer la prueba, si es una variable local no apunta a nil, siendo así con el codigo anterior entra al if libera y al intentar crear te sale un AccessViolation. Estaba haciendo un procedimiento donde mi Objeto es una variable Local y ya me rompiendo mi cabeza porque no estaba funcionando bien, ahora veo que no estaba apuntando a nil, en mi programa en una parte según una condición creaba mi objeto y mas abajo preguntaba si estaba creado entonces que haga algo. ¿Me pueden explicar porque no apunta a nil cuando es variable local, la solución para una variable local sería hacer que ese tu objeto apunte a nil antes de hacer algo?.

Cecilio, libera tu ClientDataSet con FreeAndNil como te dice Neftali.

Saluditos

[[Lepe]]

No sé el por qué, quizás por eficiencia, tarda menos en ejecutar procedimientos locales porque no tiene que inicializar las variables.

Muchas veces es redundante, delphi la inicializa y nosotros la usamos en un bucle for que también la inicializa.... pues ... ¿pá qué? .

Mi comentario es sólo para añadir que pasa con todas las variables locales, incluso un Integer, currency, etc no tendrá el valor cero como puede esperarse.

Saludos

[*Caro*]

Empezado por Lepe

Mi comentario es sólo para añadir que pasa con todas las variables locales, incluso un Integer, currency, etc no tendrá el valor cero como puede esperarse.

Hola Lepe, gracias por responder, se que pasa eso con los demas tipos (integer,......), pero no pense que pasaba lo mismo con un objeto que no ha sido creado aun. Pense, que si defino mi variable, digamos mi ClientDataSet : TClientDAtaSet, con eso tendría una referencia al objeto de tipo TClientDataSet, por lo que pense que esa variable apuntaba a nil, ya que no lo hemos creado todavía.

No hay problema entonces la solución sería cuando tenga un objeto como variable local inicializarlo en nil aunque no lo haya creado, para no tener problemas en el caso que describo en mi anterior mensaje.

Saluditos