Destroy de mala madre...

[Xianto]

Hola... estoy enojadete (como diria Flanders) con un componente...

Se trata de un TADODataSet.. veamos un poco de código:

Código Delphi [-]
procedure pepe()
var rec: integer;
    vIndex: integer;
    ADORecs: array [0..4] of TADODataSet;
begin
  for x := 0 to 4 do
    begin
        ADORecs[x].Free;
    end;
  vIndex := 0;
  ADORecs[vIndex] := TADODataSet.Create(Self);
    with ADORecs[vIndex] do
      begin
        Name := 'ADORecs'+IntToStr(vIndex);
        CursorType := ctStatic;
        LockType := ltReadOnly;
      end;
..........
end;

El problema es simple, ejecuto el procedimiento con una sola query por lo que solo uso un solo ADODataSet, que en el primer caso el Name seria ADORecs0... hasta ahi todo bien...

El problema al ejecutar el procedimiento una segunda vez, ya que al pasar por la linea: Name := 'ADORecs'+IntToStr(vIndex), intenta nuevamente dar el nombre de ADORecs0, pero el nombre existe, por lo cual el componente no fue destruido...

Como puedo hacer para eliminarlo a el y a los suyos de una vez y por todas sin que me falle de nuevo ???

Desde ya agradecidito.... jejeje

[delphi.com.ar]

Por lo que veo, la variable ADORecs es local del procedimiento y dinámica, por lo que cada vez que entre al procedimiento será una nueva variable, por lo que no contendrá el TDataSet que has asignado anteriormente.
Simplemente o utiliza una variable estática, o sácala del procedimiento.

Saludos!

[jachguate]

Es una saludable práctica de programación destruir todo objeto que se cree cuando deja de ser útil. En tu caso, crear instancias de objetos asignadas a variables locales debería obligarte, cuando menos, a destruirlas antes de salir del procedimiento.

Esto alivia, no solo el problema en cuestión, sino el mas grave problema de consumir recursos y jamás devolverlos, con lo cual la ya frecuente necesidad de reiniciar de windows puede volverse un verdadero dolor de cabeza.

El código quedaria algo asi:

Código Delphi [-]
procedure pepe()
var rec: integer;
    vIndex: integer;
    ADORecs: array [0..4] of TADODataSet;
begin
  vIndex := 0;
  ADORecs[vIndex] := TADODataSet.Create(Self);
  try
    with ADORecs[vIndex] do
      begin
        Name := 'ADORecs'+IntToStr(vIndex);
        CursorType := ctStatic;
        LockType := ltReadOnly;
      end;
     ..........
  finally
    for x :=  0 to 4 do
      AdoRecs[0].Free;
  end;
end;

Lo he encerrado el un bloque try/fianlly para que se libere sin problemas aún cuando ocurra alguna excepción en la ejecución del bloque.

Saludos.
Saludos.

[mamcx]

Ahora bien, usar un TObjectList tambien seria util. Aunque habria que hacer un cast el manejo de la memoria es automatico y el codigo quedaria en ultimas mas compacto... en mi opinion...

[jachguate]

Podrias explicar cual es la ventaja de usar un TObjectList en este caso particular?

[[Al González]]

¡Buen día a todos!

La solución más adecuada es la que propone Antonio. Cuando una rutina necesita crear un objeto que solamente esa rutina utilizará, es conveniente que en ella se tenga el código que destruya el objeto una vez que ya ha sido utilizado. Para asegurar que la memoria ocupada por el objeto sea liberada finalmente, aunque surjan errores (excepciones) en su utilización, suele emplearse un bloque de protección Try-Finally, como bien lo sugiere Antonio.

El problema principal en el código de Xianto es que en lugar de crear el objeto y luego destruirlo, primero tiene el código de destrucción y luego el de creación, de tal suerte, que cuando la rutina termina, el objeto sigue existiendo y adueñado por el objeto «Self» (considerando que el procedimiento «Pepe» es en realidad un método de alguna clase de objeto).

Delphi.com.ar: Según el código de Xianto la variable ADORecs si es estática, no dinámica.

Espero esto sea de utilidad, seguimos en contacto.

Al González.

[mamcx]

El manejo de la memoria es automatico... Pero viendo el codigo y teniendo en cuenta que la matriz es de tamaño fijo no es tan buena idea despues de todo... Seria una opcion si se requiere algo mas dinamico pero en este caso ya dieron la mejor respuesta...

[delphi.com.ar]

Pues por el código original, me da la sensación que Xianto quiere que los objetos se liberen cuando se vuelve a llamar al procedure, no conozco la lógica del programa, pero por eso he propuesto esa solución. Sería bueno conocer su opinión!

[jachguate]

Creo que ya entramos al terreno de las suposiciones... será mejor que Xianto nos aclare un poco.

A mi me parece, en vista del código, que en realidad es un descuido al programar, pues no veo de que manera podrian ser accesibles los datos desde fuera, a menos que se asociaran a controles visuales y a través de esto se hiciera, pero igual me parece muy retorcida la idea de hacer esto con una variable local.

Igual, si se hubiese enlazado, podria intentar destruirse antes de volver a crearlo con algo como:

Código Delphi [-]
  if assigned(dbEdit1.Datasource.DataSet) Then
    dbEdit1.DataSource.DataSet.Free;

De cualquier forma esto no me parece nada recomendable.

Hasta luego y un saludo delphi.com.ar

[delphi.com.ar]

Empezado por Al González

Delphi.com.ar: Según el código de Xianto la variable ADORecs si es estática, no dinámica.

Mmmmm.. No estoy de acuerdo con eso, la variable ADORecs es una viariable dinámica, se creará cada vez que se ejecute el procedimiento. Puede que la confusión resida en que ADORecs es un array estático y no dinámico.

Typed Constants

Saludos!