constructor y destructor

[roman]

Empezado por gustavo2

La creacion en tiempo de ejecucion de objetos es mi duda.

Ok, entonces es una pregunta acerca de objetos y realmente no tiene que ver con tablas planas de manera que deberías haberlo puesto en el foro OOP.

Para construir un objeto en tiempo de ejecución tienes que usar su constructor- en la inmensa mayoría de casos se llamará Create. Digamos que tienes una clase TMiClase y deseas crear un objeto de esta clase; si tienes una variable de tipo TMiClase bastará que le asignes el resultado del constructor:

var
  UnObjeto: TMiClase;

...

UnObjeto := TMiClase.Create(parámetros);

Pasando los parámetros pertinentes según la clase de que se trate y llenando las propiedades necesarias. En tu caso particular, necesitas un grid, una tabla y un datasource por cada tabla física:

var
  Grid: TDBGrid;
  Table: TTable;
  DSource: TDataSource;

begin
  Table := TTable.Create(nil);
  DSource := TDataSource.Create(nil);
  Grid := TDBGrid.Create(nil);

  Table.DatabaseName := alias de la base de datos;
  Table.TableName := nombre de la tabla física;
  
  DSource.DataSet := Table;

  DBGrid.DataSource := DSource;  
end;

Fíjate en el parámetro (nil en el ejemplo) de los constructores. Este parámetro es una componente que será la encargada de destruir al objeto cuando ella misma se destruya. Cuando en tiempo de diseño insertas componentes como Table en el formulario, este parámetro automáticamente se asigna al formulario mismo de manera que cuando el formulario se destruye (sea porque termina la aplicación o porque explícitamente lo hagas en código) él destruirá también a todas las componentes que posee, razón por la cual no necesitas hacerlo tú mismo. Sin embargo, si requieres destruir las componentes antes de que termine la aplicación para liberar memoria entonces te conviene pasar nil como parámetro lo cual querrá decir que nadie se va a encargar de destruirlas de forma automática y lo harás tú mismo cuando sea necesario:

Table.Free;
DSource.Free;
Grid.Free;

Ahora bie, dado que la cantidad de tablas que crees en la ejecución no es fija sino que depende de condiciones que de el usuario, te convendrá mantener una lista dinámica de ellas, por ejemplo, con un TObjectList:

type
  TDataPack = class
    Table: TTable;
    DSource: TDataSource;
    Grid: TDBGrid;
  end;

En cada item de la lista pondrías un "pack" o conjunto de las tres componentes requeridas:

var
  Pack: TDataPack;

begin
  Pack := TPack.Create;
  Pack.Table := TTable.Create(nil);
  Pack.DSource := TDataSource.Create(nil);
  Pack.Grid := TDBGrid.Create(nil);

  List.Add(Pack); // List es de tipo TObjectList
end;

y llenas el resto de las propiedades como antes.

Recuerda que deberás crear List previamente:

List := TObjectList.Create(true);

Al pasar true como parámetro hace que la lista ´'posea' los objetos que agregas de manera que cuando destruyas la lista automáticamente se destruirán todos sus elementos.

Espero que esto te sirva de guía.

Dejame comentarte que Delphi es un lenguaje orientado a objetos de manera que es fundamental tener una noción al menos básica de éstos y como funcionan en el lenguaje. Por ello te recomiendo que leas un poco acerca de ello para no estar atorándote en cuestiones que hasta cierto punto son más o menos elementales.

// Saludos

[delphi.com.ar]

Empezado por roman

Ok, entonces es una pregunta acerca de objetos y realmente no tiene que ver con tablas planas de manera que deberías haberlo puesto en el foro OOP.

Lo muevo al foro OOP

[jachguate]

creo que esto perfectamente se puede lograr con herencia visual, simplemente asignando en un método el nombre de la tabla...

Seria mucho mas práctico, a mi entender...

Hasta luego.

[roman]

Empezado por jachguate

creo que esto perfectamente se puede lograr con herencia visual

No alcanzo a ver dónde entra la herencia visual. Quizá te refieres a simplemente a utilizar un formulario con un grid, un table y un datasource y crear varias instancias de él asignado el nombre de la tabla.

En todo caso sí, tienes razón, es mucho más sencillo.

// Saludos

[gustavo2]

Hola y Gracias
Al principio mi intención era optimizar codigo y no aprender sobre programacion orientada a objeto como roman hace referencia; (leer cuando hago referencia a metodos constructores y destructores , create) si no recorreria al help de delphi . Sobre el titulo de "duda" hace referencia al ejemplo en aplicacion y a la optimizacion del codigo para varios objetos creados en tiempo de ejecucion. Sobre "complicarse" al igual que lo anterior lo tomo con humor porque me parece una opinion apresurada y fuera de lugar ya que deseo crear ademas de ventajas para el usuario un data warehouse (ver desnormalizar) al violar la nfbc y crear campos calculados. La aclaracion de es una lenguaje orientado a objetos me parece que esta de mas ya que no creo que nadie en este foro no lo sepa.
Saludos Gustavo2......

[roman]

Empezado por gustavo2

Al principio mi intención era optimizar codigo y no aprender sobre programacion orientada a objeto como roman hace referencia;

Al principio tu intención no era clara para nadie y después se vio que tu pregunta era acerca de construcción de objetos (léase programación orientada a objetos) de manera que me es difícil entender que alguien quiera usar OOP sin aprender OOP.

Empezado por gustavo2

(leer cuando hago referencia a metodos constructores y destructores , create) si no recorreria al help de delphi . Sobre el titulo de "duda" hace referencia al ejemplo en aplicacion y a la optimizacion del codigo para varios objetos creados en tiempo de ejecucion.

Tú lo has dicho. Con conocimientos básicos, leídos del help de Delphi, puedes perfectamente saber cómo construir objetos en tiempo de ejecución.

Empezado por gustavo2

Sobre "complicarse" al igual que lo anterior lo tomo con humor porque me parece una opinion apresurada y fuera de lugar ya que deseo crear ademas de ventajas para el usuario un data warehouse (ver desnormalizar) al violar la nfbc y crear campos calculados.

De hecho no entendiste que la observación de jachguate iba para mí y no para tí. Su idea es mucho más sencilla que la mía y lo acepto tal cual, sin ponérmele al "brinco".

Empezado por gustavo2

La aclaracion de es una lenguaje orientado a objetos me parece que esta de mas ya que no creo que nadie en este foro no lo sepa.

Llevas muy pocos mensajes en los foros por lo cual no tenemos muchos medios para saber cuál es tu nivel de conocimientos. A estos foros entran muchas personas que apenas se están iniciando y dada que confundiste un problema de normalización de tablas con un problema de objetos es natural que pensemos que eres novato y de ahí la observación que era una simple recomedación. Cuando desconozco un tema nunca veo con malos ojos que alguien me haga una sugerencia.

// Saludos