TZQuery en tiempo de ejecucion....error

[BrunoBsso]

En el momento de crear el Query (si lo creás como público en tu form) éste ya pertenece a la unit de dicho form, aunque no pertenezca al form. Un query, al ser no visual, no necesita tener un padre.
Desde cualqier otra unidad/datamodule que tengas por ahí si necesitás conectar algo al Query que creaste en el FormLala, simplemente le das la dirección (FormLala.Query) y listo.

Ejemplo:
Tengo un DataModule llamado DM.
Tengo un Form llamado FBruno.
En FBruno necesito usar un QueryBruno que está en DM.
Cuando, desde mi FBruno, llamo a QueryBruno, ¿cómo lo hago?
Le indico al compilador unit.objeto -> DM.QueryBruno

Creo que se entiende.
Saludos!!!!!!!!

[[AzidRain]]

Es del todo incorrecto Caral, los componentes no son mas que objetos en sí y no residen en en ningún lado salvo en tiempo de diseño. Si creas un componente en tiempo de ejecución no es necesario indicarle en donde "reside". Cuando creamos una instancia de cualquier componente en tiempo de ejecución (como es el caso) nosotros mismos somos responsables de su "ciclo de vida" de ahí que tengamos que liberarlo por nuestra cuenta, pero insisto, no es necesario y es hasta ociosos y causa problemas definirle un "padre". Esto lo hace Delphi cuando usamos componentes en tiempo de diseño.

[tgsistemas]

personalmente opino como [AzidRain], pero explico el caso para que quede más claro.

En el caso en cuestión, sólo es necesario lanzar una consulta de recordcount con parámetros, no lleva componentes visuales asociados (dbgrids, dbtext, etc....) por lo que no le veo sentido decirle que pertenecerá a este o a otro form. Es más, la idea es convertir ese código en una función para que esté disponible desde cualquier form por lo que la creación, vida y destrucción del componente nos corresponde a nosotros.... menudo poder

Ayer estuve provando el código sin la sentencia "Parent := Form1; // donde estará el ZReadOnlyQuery" y funciona correctamente.... exactamente igual que con ella

Saludos y gracias a ambos !!!!!!

[[Caral]]

Hola
Gracias por la explicación.
Creo entender:
1- Si se declara publico y es no visible es innecesario declararle un padre, la misma unit sera este, como explica BrunoBsso
2- Un componente es un objeto y no reside en ningún lado, como explica AzidRain.
Interesantes observaciones, he aprendido mucho.
El único detalle que quedaría (para novatos) es que creo que no se puede generalizar al decir que un componente no necesita padre al ser creado en tiempo de ejecución, creo que dependerá del componente y de su ubicación.
Creo que un componente puede necesitar residir en algún lado, necesitando crearle tanto el padre como otros factores, si no de hecho ni existiría el termino padre.
Os agradezco la ampliación, estoy seguro que este tema a mas de un novato nos a sido de utilidad.
Saludos

[roman]

Nada más para afinar un poco lo que ya se ha dicho.

No confundir el término padre (parent) con dueño (owner). Sólo los componentes visuales tienen un padre. Los no visuales carecen de dicha propiedad.

El encargado de liberar recursos es el dueño, no el padre.

// Saludos

[[Caral]]

Hola
A esto es lo que quería llegar ya que se puede confundir a un novato con facilidad.
Por eso comente la necesidad de ampliar el concepto.
Estoy seguro que AzidRain se refería a los componentes NO visuales, si embargo nunca hizo o marco la diferencia como si lo hizo BrunoBsso y ahora Roman.
Todo esto por el comentario de tgsistemas el cual dice en su segundo post en forma muy general:

Empezado por tgsistemas

No tengo tan claro que en tiempo de ejecución se deba asociar un componente con "un padre" ya que al fin y al cabo, entiendo yo , se puede crear sin dependencia de nadie.

Esto fue avalado por AzidRain en sus comentarios, pero sin definir la diferencia, siempre en forma general:

Empezado por AzidRain

no es necesario definir un "padre" para ningún componente creado via código salvo que queramos que este "padre" libere los recusos del mismo.....
.........
Es redundante decirle que su padre es tal o cual forma si al final de todos modos tu mismo lo vas a liberar

No intento indicar quien o no tenga razón, intento comentar como ya lo hice, por supuesto sin conocimiento, que no se podía generalizar.
Por eso para mi poco conocimiento el comentario de BrunoBsso:

Empezado por BrunoBsso

Un query, al ser no visual, no necesita tener un padre.

Y por ultimo de Roman:

Empezado por Roman

No confundir el término padre (parent) con dueño (owner). Sólo los componentes visuales tienen un padre. Los no visuales carecen de dicha propiedad.

El encargado de liberar recursos es el dueño, no el padre.

Son los mas acertados, sin menospreciar a ningún otro y por supuesto con el afán de que el que pueda ver este hilo le quede un poco mas clara la diferencia.
Muchas gracias a todos vosotros por ampliar y aportar y a tgsistemas por dejarme invadir su hilo.
Saludos

[tgsistemas]

Hola,

tienes toda la razón [Caral] en las observaciones, cuando dije :

Empezado por tgsistemas
No tengo tan claro que en tiempo de ejecución se deba asociar un componente con "un padre" ya que al fin y al cabo, entiendo yo , se puede crear sin dependencia de nadie.

me estaba refiriendo a un componente no visual y lo debería haber especificado para que quedara bien claro. Seguramente pensé más rápido de lo que escribía y daba por hecho que todo el mundo entendía que era un componente no visual.

Perdón por la confusión, en los próximos hilos intentaré detallar al máximo la info para no confundir.

Muchas gracias a todos, en especial a tí [Caral] por la ayuda y sobre todo en Domingo !!!!