Saber si se ha creado un objeto

[Cecilio]

Hola.

Tengo un TclientDataSet que se crea en tiempo de ejecución, es de ambito global.
Y me gustaría saber si se ha creado previamente.

He probado esto pero no va:

Código Delphi [-]
if ds=nil then
 ds.create(self)
else
 ds.free;

[*Caro*]

Hola Cecilio, para ello tienes el Assigned.

Código Delphi [-]
 if Assigned(ClientDataSet) then
  showmessage('si')
 else
  showmessage('no');

Saluditos

[Cecilio]

Caro. Gracias por la prontitud.

[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

Código Delphi [-]
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)

// Saludos

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

También sería bueno, que si en el código lo liberas para volver a crearlo, te asegures de que al liberar coge valor nil.

Código Delphi [-]
  // para liberar
  FreeAndNil(ClientDataSet);

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

[donald shimoda]

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.

Con el único fin de enriquecer la charla en tiempo de diseño Assigned triunfa donde pepe <> nil falla.

Documento.

Saludos.

[donald shimoda]

Empezado por roman

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)


// Saludos

Solo con el ánimo de enriquecer la charla (no se puede poner como encabezado? Asi no me meten infracciones los policías del foro )

Esto es absolutamente válido :

Código Delphi [-]
procedure HacerAlgoyLimpiar;
var
  ds : TClientDataSet;
begin
  try
    ds.create(self);
    // hacer algo con DS
  finally
    FreeAndNil(ds);
  end;
end.

Saludos

[[Lepe]]

OFFTOPIC: Me alegra que te vayas "re-educando", lo digo porque sin el enlace al documento, tendríamos otra divertida polémica.

Te agradezco por mi parte, ese enlace. Primero usaba F <> nil, después de un tiempo me acostumbré a usar Assigned, y desde hace poco dije, ¿qué diferencia hay? pues nada vuelvo a lo de siempre, y como digo, desde hace poco volví a usar F <> nil, ni siquiera lo puse en duda ni busqué en internet.

Desde ahora queda claro que usaré Assigned.

Repito, gracias.

[donald shimoda]

Empezado por Lepe

OFFTOPIC: Me alegra que te vayas "re-educando", lo digo porque sin el enlace al documento, tendríamos otra divertida polémica.

Desde ahora queda claro que usaré Assigned.

Empezado por Lepe

Repito, gracias.

Gracias por las gracias.

[roman]

Empezado por roman

Assigned es esencialmente lo mismo que la comparación con nil por lo que si falla uno también el otro.

Como dije, Assigned es esencialmente lo mismo que la comparación con nil. Puse la palabra esencial, precisamente porque acababa de ver el artículo que citaron. Aunque si se lee con cuidado, notarán que la diferencia no aplica en el caso de un objeto sino de un apuntador a método.

De todas formas, a mi en lo particular me gusta más usar Assigned en todo caso, por una cuestión de legibilidad, pero eso ya es gusto personal.

Empezado por Caro

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

Así es en efecto Caro, la misma documentación de Delphi señala que las variables locales no se inicializan. La razón la desconozco, aunque pudiera deberse a que esas variables viven en la pila o stack de manera que, en realidad, no hay nada que inicializar sino hasta que se llama la función.

Empezado por donald shimoda

Esto es absolutamente válido :

Código Delphi [-]
procedure HacerAlgoyLimpiar;
var
  ds : TClientDataSet;
begin
  try
    ds.create(self);
    // hacer algo con DS
  finally
    FreeAndNil(ds);
  end;
end.

No sé a qué te refieres con válido. Quizá te refieras a que compila, lo cual es cierto. Pero para que futuros lectores no se confundan creo que es bueno aclarar que una construcción así es garantía de problemas.

// Saludos

[*Caro*]

Empezado por roman

Así es en efecto Caro, la misma documentación de Delphi señala que las variables locales no se inicializan. La razón la desconozco, aunque pudiera deberse a que esas variables viven en la pila o stack de manera que, en realidad, no hay nada que inicializar sino hasta que se llama la función.

Muchísimas gracias por responder Roman .

Saluditos

[donald shimoda]

Empezado por roman

De todas formas, a mi en lo particular me gusta más usar Assigned en todo caso, por una cuestión de legibilidad, pero eso ya es gusto personal.

Opino igual.

Empezado por roman

No sé a qué te refieres con válido. Quizá te refieras a que compila,

Compila y funciona.Si la idea es usar el objeto de manera temporal cumple con el propósito.

Empezado por roman

lo cual es cierto. Pero para que futuros lectores no se confundan creo que es bueno aclarar que una construcción así es garantía de problemas.

// Saludos

Podrías explicar porque?

Saludos

[roman]

Empezado por donald shimoda

Podrías explicar porque?

Copiando y pegando tu ejemplo:

---------------------------
Project1
---------------------------
Access violation at address 00403578 in module 'Project1.exe'. Read of address 7A836652.
---------------------------
Aceptar
---------------------------

// Saludos

[[eduarcol]]

Donald, quizas deberias cambiar esta linea:

Código Delphi [-]
ds.create(self);

por esta otra.

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

de esta manera estas instanciando la clase dentro de un objeto, en el ejemplo anterior lo asignas como perteneciente a esa clase, pero nunca se inicializa.

[roman]

A manera de explicación a los compañeros que no les quede claro, digamos que un constructor como TObject.Create llama en automático al método de clase NewInstance. Siendo un método de clase, NewInstance (al igual que el constructor) existe independientemente de cualquier instancia de la clase, y es el encargado de asignar memoria para el nuevo objeto y devuelve un apuntador (referencia) a dicho objeto. Ese valor devuelto es el que se asigna a la referencia en una construcción como

Código Delphi [-]
ds := TClientDataSet.Create(...);

Si simplemente hacemos

Código Delphi [-]
ds.Create(...);

el objeto sí se crea, pero nunca lo asignamos a la variable ds y de ahí todos los riesgo de violación de acceso, pues ds, al no haber sido inicializado, apunta a un lugar "aleatorío" en la memoria (o nil en el caso de variables globales).

En resumen, el objeto existe, pero ds no apunta a él.

// Saludos

[[eduarcol]]

Bueno Roman, gracias por escribir lo que te explique, no encontraba las palabras, te equivocastes en unas cositas pero no importa

[roman]

Disculpa Eduardo, trataré de poner más atención la próxima vez

// Saludos