Entendiendo al inspector de objetos

[delphi.com.ar]

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]

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]

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]

Ok delphi.com.ar

(Seguramente posteamos al mismo tiempo, jeje!)

[[Al González]]

¡Hola a todos!

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.

[[Crandel]]

La verdad es que me gusto este hilo, nunca habia pensado en la pregunta y mucho menos sabia la respuesta, asi que los felicito a todos.

Ahora si pensamos del lado opuesto (del lado de Borland), como resolver el problema de donde ir guardando la información que el usuario va generando por defecto.

La primera idea podría ser asignarle en el método create todos los valores por defecto a la clase, suena lógico pero tiene muchos problemas.

Primero supondría que podría haber objetos que todavia no se crearon por lo tendriamos un problema.

La cantidad de código que se generaría en el constructor sería enorme, lo cual haría engorroso una simple unit.

Podría haber más soluciones pero dejemos que la pisen ellos , aunque seguramente ya lo hicieron, y decidieron que esta era la que más le gustaba.

[roman]

Empezado por Crandel

nunca habia pensado en la pregunta y mucho menos sabia la respuesta

Tampoco yo había caido en la cuenta de ello. La duda me surgió cuando intentaba usar un DataModule para cada objeto de la aplicación, TdmCliente, TdmFactura, TdmPedido, etc. y por otro lado, un formulario de edición de cada tipo de objeto, TfrmCliente, TfrmFactura, TfrmPedido, etc. Cada data module tenía su propio Query y cada formulario su correspondiente DataSource. De manera que lo natural era enlazar unos con otros durante el diseño, como es costumbre. Sin embargo, en determinado momento pensé que me convendría crear más de un mismo tipo de objeto para el caso de que tuviera que acceder a dos objetos de la misma clase al mismo tiempo (tanto el módulos de datos como el formulario). Ahí es donde ya no queda claro qué está conectado con qué y donde, como dice Al, este tipo de asociaciones no están pensadas para ser muchos a muchos.

Me parece interesante el problema porque cuando uno trabaja de la forma canónica (una sóla instancia del módulo de datos), diera la impresión de que el enlace que uno hace en el diseño es un enlace a nivel de clases, pero no es así (y creo que ni debiera ser así) sino a nivel de objetos (instancias).

Claro que tal asociación múltiple puede establecerse como debe ser, por código asignando manualmente las componentes al momento de la creación.

Pero el aprendizaje para mí es, nuevamente, mirar con mucho cuidado lo que se hace en tiempo de diseño.

// Saludos

[roman]

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