Entendiendo al inspector de objetos

roman · #1 22-08-2005

Nunca había caido en la cuenta de algo que, al menos a mi, me parece extraño. Quizá alguien puede explicar lo que realmente sucede.

Vamos a suponer que tenemos un formulario MainForm y un data module DMData.

En el data module colocamos una componente Table y en el formulario un DataSource.

Incluimos la unidad del data module en la cláusula uses del formulario con lo cual podemos asignar el Table de DMData a la propiedad DataSet del DataSource del formulario.

Nada fuera de lo común. Supongo que muchos habremos hecho esto cientos de veces: conectar un datasource de un formulario a un dataset de un data module.

Pues bien; mi pregunta es, ¿a dónde realmente apunta MainForm.DataSource.DataSet?

Dirán ustedes: pues a DMData.Table, ¡lo acabas tú mismo de decir!

Más aún, si vemos el archivo DFM del formulario es justo lo que vemos:

Código Delphi [-]  object DataSource: TDataSource
    DataSet = DMData.Table
    Left = 464
    Top = 8
  end

Pero mi duda comienza aquí:

Cuando agregamos un data module a nuestro proyecto durante el diseño y le insertamos componentes, declaramos propiedades e implementamos métodos, se supone que estamos definiendo una clase, no construyendo un objeto. Y puede haber más de un objeto de esta clase.

Así pues, reformulo la pregunta:

¿A qué instancia de la clase TDMData pertenece la componente Table a la que apunta MainForm.DataSource.DataSet?

Una primera respuesta sería decir que a la variable DMData que Delphi crea por defecto.

Bueno, pues ahora borren esa variable y quítenla del auto-create:

Código Delphi [-]type
  TDMData = class(TDataModule)
    Table: TTable;
    procedure DataModuleCreate(Sender: TObject);
  end;

(* no usar la variable declarada por Delphi
var
  DMData: TDMData;
*)

Si creamos una instancia de TDMData durante la ejecución:

Código Delphi [-]with TDMData.Create(Self) do
begin
  Table.Open;
end;

todo funciona igual. Los controles conectados a MainForm.DataSource muestran correctamente los datos de la tabla en DMData.Table.

Pero, ¿si creamos varias instancias de TDMData? ¿A cuál apunta MainForm.DataSource.DataSet?

Aparentemente a la primera que se haya creado.

¿Cómo hace la VCL para determinar a dónde debe apuntar MainForm.DataSource.DataSet?

// Saludos

jmariano · #2 22-08-2005

Saludos!

La verdad es que es bastante curiosa tu pregunta, asi que he estado revisando un poco los fuentes de Delphi para ver si descubría cómo y, resulta, que se da una cosa interesante. Si creamos el módulo de datos sin que lea el archivo de recursos:

Código Delphi [-]  DMData := TDMData.CreateNew(Self);
  DMData.Table := TTable.Create(DMData);
  ...
  DMData.Table.Open;

veremos que ya no ocurre la asignación automática para la propiedad MainForm.DataSource.DataSet, quedándo esta propiedad con el valor nulo.

Si revisamos el método Create() del TDataModule veremos que llama a la función "InitInheritedComponent", ésta función lo que hace es cargar el archivo .dfm del componente y darle así valores a las diferentes propiedades. Si analizamos esta función nos encontraremos con un bucle que llama repetidamente otra función "InternalReadComponentRes" (si analizamos esta última veremos que es la que se encarga realmente de cargar los recursos para cada componente, de hecho localiza los recursos bajo el nombre "RT_RCDATA", ¿os suena?) y, además, llama a tres métodos más: BeginGlobalLoading, NotifyGlobalLoading y EndGlobalLoading. Estos últimos tres métodos, si miramos el código, veremos que lo que hacen es llamar a todos los métodos "Loaded" de una lista de componentes "globales" (es decir, o al menos creo yo, componentes que se han ido creando durante la ejecución).

Conclusión, creo que Delphi, en tiempo de ejecución, al invocar el método "InitInheritedComponent" para leer el archivo de recursos del módulo de datos o formulario (si haceis la prueba con un formulario, en vez de con un móddulo de datos, vereis que pasa exactamente lo mismo) "vuelve" a leer los recursos de todos los componentes que ya fueron cargados y por eso consigue hacer la asignación para la propiedad de la que hablábamos antes: MainForm.DataSource.DataSet. (Esta conclusión la baso en que si no cargamos el archivo de recursos, entonces, Delphi no consigue hacer la asignación).

Y para terminar solo decir que el método "InitInheritedComponent" sólo es invocado por los módulos de datos y por los formularios (que son los únicos que no necesitan ser "depositados" dentro de un control).

Chao!

delphi.com.ar · #3 22-08-2005

Recuerda que el DFM no se compila, por eso no da un error a la hora de compilar el proyecto si lo daría si tuvieramos esa referencia por código (Para mi este es uno de los pocos puntos en contra de Delphi). Por otro lado, si bien en el DFM las referencias se guardan por nombre, bien sabemos que Delphi referencia a los objetos por los punteros de los mismos.
Por una ojeada no en profundidad, me parece que la respuesta esta en la función Classes.GlobalFixupReferences, cuando lee el DFM del form y no encuentra fácilmente la referencia a un control (TReader.DoFixupReferences), la agrega a la lista GlobalFixupList (GlobalFixupList.Add(FFixups[i])

, al terminar del leer el DFM, ejecuta esta función busca al DataModule con FindGlobalComponent y busca el componente dentro con FindNestedComponent....
Obviamente como FindGlobalComponent utiliza la lista de los objetos globales registrados, va a tomar el primero de la lista, es decir, el primero que se registró.

Saludos!

jmariano · #4 22-08-2005

Mas que compilarlo lo que hace es guardar la información del .DFM dentro del ejecutable (de hecho, si usas algun visualizador de recursos y analizas un .exe generado por Delphi verás que bajo la clave "RCDATA" podrás leer todo el contenido que tenía el .DFM, ni siquiera está encriptado ni nada), y en tiempo de ejecución lo que hace es leerlo invocando al método que comente antes "InitInheritedComponent".

Aunque has sido más especifico que yo y, seguramente, sea ese el método que resuelve las referencias. Pero si te fijas la función "GlobalFixupReferences" es invocada dentro del método "ReadRootComponent" que pertenece a la clase "TReader" y si analizas la función "InternalReadComponentRes" (que es invocada por "InitInheritedComponent" dentro del constructor del módulo o formulario) verás que crea un objeto, "TResourceStream", y llama al método "ReadComponent" que es el que crea la clase "TReader" y llama a "ReadRootComponent". (Es decir, el contenido del archivo de recursos es leído en tiempo de ejecución desde el ejecutable, y éste contiene el nombre del objeto, tipo y subcomponentes que posea).

Chao!

delphi.com.ar · #5 22-08-2005

Cuando escribí mi mensaje el tuyo no estaba

... le respondí a Román no a tu pregunta!

... y siendo Román el que inició el hilo, di por supuestos muchos detalles, por eso me detuve en GlobalFixupReferences y no mas "arriba"

Saludos!

jmariano · #6 22-08-2005

Ok delphi.com.ar

(Seguramente posteamos al mismo tiempo, jeje!)

[Al González] · #7 23-08-2005

¡Hola a todos!

Cita:

Empezado por roman

...Este tipo de asignaciones, de propiedades a componentes en otro formulario o módulo de datos, hechas en diseño, presuponen en el fondo que sólo habrá una instancia de tal formulario...

Así es Román, tal parece que así lo diseñó Borland. Y es que en tiempo de diseño no puede saberse cuántas instancias de una forma o módulo de datos creará el programa en tiempo de ejecución. Así que lo más lógico es encadenar con la primera instancia que exista. Por otra parte, se puede ver desde la óptica de que los enlaces entre fórmas o módulos de datos generalmente son uno a uno o uno a muchos, pero pocas veces muchos a muchos (donde si tendría efecto negativo el mecanismo de asignación mencionado).

Algunas veces he navegado en las profundas aguas de las clases TReader y similares, como cuando me pregunté por qué Delphi 3 no guardaba los valores asignados a propiedades publicadas de un objeto TCollection (simplemente alguien en Borland no lo tomó en cuenta

, lo bueno es que Delphi 7 si lo hace

).

Confieso que me resultaba un poco agotador seguirle la pista cuántica a los caminos "clasificados" de la VCL. Por lo que veo a Federico y Mariano les resulta más fácil bucear a esa profundidad.

Un abrazo abismal.

Al González.

roman · #8 22-08-2005

Pues muchas gracias por sus respuestas, me han dejado sin palabras. Ustedes sí que entienden las profundidades de la VCL (no lo digo con ironía sino con respeto).

Lo que explican suena muy lógico. Nunca antes había pensado en esto y no deja de disturbarme un poco. Este tipo de asignaciones, de propiedades a componentes en otro formulario o módulo de datos, hechas en diseño, presuponen en el fondo que sólo habrá una instancia de tal formulario.

// Saludos