Saber si se ha creado un objeto

[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

[Dado de baja]

Gracias de nuevo a todos.

La verdad es que ya uso assigned(loquesea).
Desde que lo usé no volvió a dar problemas.

Tambien estoy usando lo que aconsejasteis: FreeAndNil para otros casos, no para el que estaba trabajando cuando la consulta en el foro, ya que ese ClientDataset solo se libera al terminar el programa. Cada método comprueba con assigned si está creado y si no lo crea asi:
cds:= TClientDataSet.create(self)

Aunque en el foro puse ds.create(self) realmente nunca lo creo así. Lo puse así por la rapidez ya que lo importante era la comparación a nil del If, ni tampoco lo libero, ya que se libera en onClose de la form.

El programa va de lujo usando el assigned

[donald shimoda]

Empezado por roman

Copiando y pegando tu ejemplo:

// Saludos

Irrefutable. Me equivoqué feo.

Quería mostrar el caso en que un objeto que se crea y usa de una vez, sin necesidad de acceder mas tarde a este, caso una tarea que se crea para que realice cierto proceso y se destruye sola al terminar en ese caso si es valido algo como:

Código Delphi [-]
  
TMiTarea.create;

No aplica a TClientDataset , ni cerca.

Saludos.

[roman]

¡Ah! Ok. Si todo se hace en el constructor pues es posible que pueda llamarse a Create desde una variable en lugar de referencia de clase misma. Aunque serán casos raros ¿no?

// Saludos

[donald shimoda]

Empezado por roman

¡Ah! Ok. Si todo se hace en el constructor pues es posible que pueda llamarse a Create desde una variable en lugar de referencia de clase misma. Aunque serán casos raros ¿no?

// Saludos

Si pero se da para una tarea concretamente, que no vaya a ser monitoreada. El create asigna los parámetros de arranque y la dispara con Resume, y se olvida de ella.

las he usado en algunas ocasiones.

Saludos.

[[maeyanes]]

Hola...

Aquí metiendo mi cuchara

En algunas ocasiones se puede hacer para ejecutar hilos (TThread), yo lo he hecho en alguna ocasión, simplemente hago:

Código Delphi [-]
TMiHilo.Create(True); // El constructor redefinido Create inicializa la propiedad FreeOnTerminate a True

Saludos...

[roman]

Je, je, ahora ya estamos con los TThread. Pues sí, es como dices maeyanes. E incluso para otro tipo de situaciones puede definirse un método de clase que se encargue de instanciar un objeto, hacer cositas con él, liberarlo y se acabó.

Por ejemplo, si tenemos una clase TPropiedadesPersona, derivado de TForm para editar las propiedades de un objeto TPersona, puede definirse un método de clase:

Código Delphi [-]
type
  TPropiedadesPersona = class(TForm)
     ...
  public
    property Persona: TPersona .....;
    class procedure Editar(P: TPersona);
  end;

...

class procedure TPersona.Editar(P: TPersona);
var
  Form: TPropiedadesPersona;

begin
  Form := TPropiedadesPersona.Create(nil);
  Form.Persona := P;

  try
    Form.ShowModal;
  finally
    Form.Free;
  end;
end;

De esta manera, para editar las propiedades, simplemente haríamos:

Código Delphi [-]
TPropiedadesPersona.Editar(P);

sin más nada.

// Saludos

[[maeyanes]]

Hola

Solo que un método de clase se declara como:

Código Delphi [-]
class procedure Editar(P: TPersona);

A menos que esté desactualizado



Saludos....

[[Delphius]]

Empezado por donald shimoda

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

Documento.

Saludos.

¡Ufff... como tengo oxidado el inglés!
Parece que no basta con tener el diccionario de 2 kilos. En algún momento tendré que volver a tomar cursos de inglés.

Si no es molestia, ¿Alguien podría resumirlo en castellano?

No me queda muy en claro la relación de dicho documento con lo tratado aquí. Y lo digo precisamente por lo que leo... ¡Habla sobre punteros a métodos! Tal como lo ha señalado roman:

Empezado por roman

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.

No es por traer problemas, pero es que me gustaría poder entender correctamente la diferencia de emplear Assigned entre objetos y métodos.

Saludos,