27 respuestas en este tema

[Marc]

Hola amigos.

¿ No os dan problemas los formularios con muchos controles no-visuales cargados en ellos (dataclients, datasets, datasetproviders, ....) ?. Yo en algunas pantallas no sé que hacer con ellos, tengo decenas de controles no-visuales y hay que disponerlos de forma que puedas acceder a ellos, pero a la vez tienes que evitar que oculten los controles visuales (TEdits, TLabels, ...) de la pantalla que hay debajo.

Yo creía que con los nuevos IDE's de Delphi, los controles no-visuales ya se podían poner fuera de la pantalla (como hace Visual Studio, que si no me equivoco los ubica debajo del formulario). Pero nunca he visto la forma de hacerlo.

¿ Sabéis si es posible moverlos fuera del área del formulario sin tener que crear un TDataModule donde moverlo todo y tener que enlazarlos en tiempo de ejecución ?.

Gracias.

[Rolphy Reyes]

Saludos.

Básicamente, el lugar ideal para ellos es un DataModule, hasta tanto los IDE no soporten la misma funcionalidad que Visual Studio.

En mis desarrollos personales tengo un TDataSource en los formularios y un TDataModule tengo los TDataSet necesarios, por cada tabla tengo un TDataModule y cada TForm sabe que TDataModule debe instanciar conjuntamente con sus relacionados.  Además tengo un TDataModule general (se crea al inicio de la aplicación) donde pongo los componentes que son de uso compartido.

Al final mis TForm tienen alrededor de uno a tres componentes no visuales, dependiendo del objetivo del formulario; mi meta es que los TForm solo sirven para presentar datos y la lógica de las operaciones residan en un TDataModule, esto me da la flexibilidad de que puedo cambiar los TForm sin mucho esfuerzo.

[felipe]

Pues al igual que Rolphy el uso de los TDataModule viene siendo la opción más adecuada, en mi caso no uso uno por cada tabla sino solo un gran y general para todos los componentes de conexión y similares, ya desde cada formulario se abre y se cierran las consultas que haga cada una para no cargar toda la memoria. El problema como bien dices, es que aunque son no visuales, si lo son en tiempo de diseño, incluso tienen la propiedad de enviar al fondo o traer al frente, no debería ser así, puesto que "estorban" al diseñar el formulario.

Si no es muy tedioso el trabajo de migrar los componentes al TDataModule te sería lo más adecuado.


Saludos!

[Delphius]

Hola Marc,

No exploré todas las funcionalidades de CnPack pero cuenta (y creo que también GExperts) con una opción que te permite (des)ocultar los componentes visuales en cuanto uno desee.
También tiene entre sus funciones la posibilidad de organizar todos los componentes... jugando con ello se podría hacer algo, que si bien no será igual, al efecto que tiene Visual Studio (que debo decir que no conozco cual es el dichoso efecto, no logro entender bien lo que hace, ya que no lo uso).

Saludos,

[Marc]

Gracias chicos, es lo que me temía. Normalmente tengo pocos controles y no molestan, pero hay una decena de formularios que están muy cargados, y en esos casos sí que acaba siendo molesto trabajar teniendo los controles siempre por en medio.

Hola Marc,

No exploré todas las funcionalidades de CnPack pero cuenta (y creo que también GExperts) con una opción que te permite (des)ocultar los componentes visuales en cuanto uno desee.
También tiene entre sus funciones la posibilidad de organizar todos los componentes... jugando con ello se podría hacer algo, que si bien no será igual, al efecto que tiene Visual Studio (que debo decir que no conozco cual es el dichoso efecto, no logro entender bien lo que hace, ya que no lo uso).

Saludos,

Esto es muy interesante, algo así me vendría de maravilla para las pocas ocasiones en que tengo que modificar esos formularios.

Siempre he trabajado con GExperts, pero no conocía esa función. La he buscado y a primera vista no la encuentro, voy a rebuscar un poco más. En caso contrario probaré la CnPack.

Gracias .

[Desart]

hola Marc Mírate este link y aquí esta para CNPACK

[andres1569]

Pues yo acostumbro a meterlos encima de un control que tenga una superficie grande y blanca  , un DBGrid, un Panel ..., donde sean fácilmente diferenciables, aunque a veces es casi imposible buscarles acomodo. En ocasiones he llegado a meterlos ocultos en la parte de abajo del Form (es decir con un Top mayor que el alto del formulario) para que no me estorbaran.

En cuanto a usar un DataModule, no siempre es aconsejable o fácil, no me refiero a los DataSets y derivados sino a los componentes no-visuales tipo ActionList, Dialogs varios, Timers ... u otros que van ligados estrechamente al formulario que los usa, el colocarlos en un DataModule, aparte de tener que instanciarlo, crea problemas con aquellos eventos que necesitan interactuar con el mismo form.

Saludos

Marc, una pequeña corrección, los controles son visuales por definición, te refieres a componentes no visuales   

[Marc]

hola Marc Mírate este link y aquí esta para CNPACK

Gracias, lástima que las GExperts no lo integren, pero me vale la pena instalar un nuevo Experto aunque solo sea para esto.

[Marc]

Pues yo acostumbro a meterlos encima de un control que tenga una superficie grande y blanca  , un DBGrid, un Panel ..., donde sean fácilmente diferenciables, aunque a veces es casi imposible buscarles acomodo. En ocasiones he llegado a meterlos ocultos en la parte de abajo del Form (es decir con un Top mayor que el alto del formulario) para que no me estorbaran.

Sí, yo intento hacer lo mismo (intento ponerlos dentro de los huecos interiores de las Grids, que suelen ser los componentes que ocupan más espacio).

El problema es que mis formularios siempre suelen estar muy cargados, y por eso muchas veces tienen PageControls, entonces los componentes no visuales no molestan con los controles de un TabSheet, pero es difícil que no tape los de otros.

Supongo que abuso demasiado de meter muchísima información en una misma pantalla (a mi, como usuario, me parece más cómodo así).

En cuanto a usar un DataModule, no siempre es aconsejable o fácil, no me refiero a los DataSets y derivados sino a los componentes no-visuales tipo ActionList, Dialogs varios, Timers ... u otros que van ligados estrechamente al formulario que los usa, el colocarlos en un DataModule, aparte de tener que instanciarlo, crea problemas con aquellos eventos que necesitan interactuar con el mismo form.

Sí, opino igual, por eso nunca me he decidido a hacer cambios masivos pasando los componentes a DataModules.

Marc, una pequeña corrección, los controles son visuales por definición, te refieres a componentes no visuales   

Tienes toda la razón. 

[Delphius]

Pues amigo Marc, no es por nada pero un form demasiado cargado es también una mala señal de que algo se está haciendo complejo o mal.

Quizá si rediseñaras la aplicación, aunque sea que tenga dos o tres forms más ganarías en facilidades para el usuario. Piensa también que no es demasiado bueno que el usuario reciba una pantalla con muchos edits, combos, o lo que fuese.

Quizá sea algo cómodo para tener todo a mano... pero también puede ser un mal a la vista.

Ahora, como te dije, CnPack tiene la opción de ocultar y mostrar los componentes no-visuales. Simplemente basta el botón secundario y haces clic en "Show/Hide Non-Visual. Lo que hace eso simplemente es "transparentarlos", invisibles, los puedes seguir seleccionando si es que te lo preguntas.
También tienes la posibilidad de organizarlos: Los seleccionas, y en la barra de Form Designer (que por defecto se mustra debajo del form) se habilita el botón "Arrange the Non-Visual Components". Alli tienes un cuadro de diálogo que te permite indicar el espaciado entre cada componente, el alineado (arriba, abajo, izquierda, derecha, etc), Que los ordene en filas, en columnas... y hasta por el nombre de la clase.

Saludos,

[Caral]

Hola
Mis form no suelen ser grandes y mucho menos uso la pantalla completa.
Lo que hago con los componentes NO-Visuales es colocarlos fuera del form (visual), pero siempre en este.
Para mi es muy cómodo usarlos en el mismo form ya que se hace mas sencillo el seguir el codigo.
Solo uso los componentes para conexión a BD en el datamodule.
Saludos

[egostar]

............al efecto que tiene Visual Studio (que debo decir que no conozco cual es el dichoso efecto, no logro entender bien lo que hace, ya que no lo uso)......

El efecto lo puedes ver en la imagen que adjunto amigo. Lo que yo hago es lo que comenta Caral, los coloco fuera de lo visible de la forma y así no los veo, aunque nos componentes de datos los coloco en Data Modules. Tambien adjunto unas imagenes.

Salud OS

Archivos adjuntos

•  2302_ca832953337950e65aa9ac4c40247f2471bd9ed0.jpg   258,87KB   18 descargas
•  2300_e389fc704e5b125c20dfe10f12897db51295b5e2.jpg   289,09KB   19 descargas
•  2298_9ee69fb3a5dc3170dcf4e6e8e1baacc6b532f0bc.jpg   863,36KB   30 descargas

[felipe]

Ego si sabe como ser ilustrativo
Aunque esa técnica no es tan mal, no parece muy recomendable y menos en un formulario tan amplio, claro, eso depende del caso. El hecho es que estar que cambiando las propiedades de tamaño del form para tener los componentes se puede volver molesto o propenso a daños en el diseño del mismo.
Ahora será esperar en una futura versión de Delphi mejoras en cuanto a estos detalles, si es que estan pensados.


Saludos!

[Sergio]

Hola Marc.

Yo personalmente tambien tengo ese problema, aunque no me preocupa, si tengo que apartar alguno para ver debajo, lo aparto y listo, no me estorban tanto como para tomarmelo en serio.

Aparte de eso, si que tienes una opcion similar a Visual Studio: Añade una TPanel con Align:= alBottom, debajo de lo que ya tengas (que en mi caso siempre es algo con Align:=alClient), en ese TPanel le pones visible:= false, y le pones encima todo lo no-visual. Listo, ya lo tienes, no te molestara y en tiempo de ejecución, el panel no existira y no ocupara ese espacio.

Low-Tech solution, pero oye, hace el trabajo!

[Marc]

Yo personalmente tambien tengo ese problema, aunque no me preocupa, si tengo que apartar alguno para ver debajo, lo aparto y listo, no me estorban tanto como para tomarmelo en serio.

Sí, tienes razón, normalmente no molestan. Pero tengo unos pocos formularios muy cargados de componentes no-visuales, y solo en ellos es un incordio buscar un hueco donde añadir uno nuevo y que moleste poco, buscar controles por debajo, etc. ...

Aparte de eso, si que tienes una opcion similar a Visual Studio: Añade una TPanel con Align:= alBottom, debajo de lo que ya tengas (que en mi caso siempre es algo con Align:=alClient), en ese TPanel le pones visible:= false, y le pones encima todo lo no-visual. Listo, ya lo tienes, no te molestara y en tiempo de ejecución, el panel no existira y no ocupara ese espacio.

Low-Tech solution, pero oye, hace el trabajo!

Jejeje, que buena solución, no se me había ocurrido . Aunque tiene el inconveniente de que entonces no ves en pantalla los controles al tamaño determinado en que se van a cargar el formulario. No es que sea un inconveniente importante, pero a veces tienes formularios con tamaño fijo, en los que no hay grids ni campos memo ni ningún otro tipo de control que compense programarlo de tamaño ajustable. Con lo que en tiempo de ejecución verías el hueco dejado por el panel de contención de componentes no visuales.

Me parece que es más cómoda la opción del CnPack (aunque te obliga a instalar un nuevo experto). Y es que con esta opción, las pocas veces en que los comonentes no visuales te molestan, pues los ocultas, sigues trabajando, y cuando has terminado los vuelves a dejar visibles. Es perfecto.

[Marc]

Hola.

Pues amigo Marc, no es por nada pero un form demasiado cargado es también una mala señal de que algo se está haciendo complejo o mal.

Quizá si rediseñaras la aplicación, aunque sea que tenga dos o tres forms más ganarías en facilidades para el usuario. Piensa también que no es demasiado bueno que el usuario reciba una pantalla con muchos edits, combos, o lo que fuese.

Mira esta pantalla, mi formulario de Terceros. Tiene 97 componentes no visuales de conexión a datos (FIBDataset, DatasetProvider, ClientDataset, DataSource, FIBQuery), a las que hay que sumar otros cuatro componentes no visuales (FIBTransaction, ImageList, RVStyle y OpenDialog). Así que aquí tengo que mantener más de 100 componentes no visuales (imagínate como están, amontonados unos encima de otros, afortunadamente nunca hay que trabajar con los DataSource y DatasetProvider, por lo que al menos estos están escondidos debajo de los ClientDataset).

El truco para que la pantalla sea operativa, es trabajar con muchas pestañas. Hay 36 pestañas para seleccionar en cada momento la información con la que quieres trabajar. Para que el usuario no se pierda buscando la pestaña que necesita, solo se muestran las pestañas necesarias en cada momento (un Cliente no necesita tener visible la pestaña de Muestrarios, por ejemplo). Además algunas pestañas se ponen dentro de pestañas., es decir, por ejemplo dentro de la pestaña de ventas tengo otro PageControl con las pestañas de Pedidos, Albaranes, Facturas y Servicios contratados.

Ya sé que este formulario es un monstruo (y tengo que admitir que tengo otros formularios que le van a la zaga). ¿ Es un mal diseño ?, no lo sé pero me parece más cómodo para el usuario, que no el ir abriendo y cerrando otros formularios.

Muestras de esta pantalla, vista desde distintas pestañas, en tiempo de diseño y ejecución :

[Delphius]

Hola Marc,
Se ve bastante bien de pinta la aplicación 

No te digo que necesariamente sea un mal diseño... únicamente trato de invitarte a pensar si es tan, pero tan necesario llegar a esos extremos.
Se que en los sistema de gestión, y sobre todo en aquellos en los que se hasta pretende controlar y administrar la cantidad de desperdicio fecal del empleado con su respectivo informe semanal y el de auditoría para controlar que realmente el momento del baño dice ser el que és y ¡que decir de esos raros informes en que se busca relacionar la cantidad de idas y los kilos dejados con la calidad de atención y los ciclos lunares! se puede llegar fácilmente a pantallas que no tienen un hueco libre.

A veces pienso que el tamaño del monitor ha seguido creciendo en cuanto a la demanda de más cosas para llenar en un form. 

¿Realmente vale la pena inundar los forms de cosas? Hay usuarios y usuarios... y para mi debe hacerse un esfuerzo en equilibrar la densidad de controles en un form respecto a la cantidad de forms en la aplicación. No estaría demás considerar algo de ergonomía visual ¿no crees?
No es tan molesto tener que abrir dos o tres forms.... distinto es si tiene que abrir 5 o más para hacer una cosa.

Saludos,

[andres1569]

Marc:

Antes que nada se ve chula la aplicación  , y tampoco creo que esté muy recargada de controles, creo que utilizas los normales en una aplicación de estas características, incluso los Ribbon de la parte superior me parecen decentes y apropiados (digo esto porque le cogí manía a los Ribbon que traen aplicaciones del MS Office, que a mi entender recargan demasiado la pantalla con tanta opción y tanto dibujito).

En cuanto al diseño, muchos de los no-visuales que hay en el formulario son de acceso a datos ¿no se podrían mover a un DataModule? Es temerario proponer esto, ya que sólo tú sabes cómo los manejas y cómo interactúan con el formulario, pero quizás algunos -estoy pensando en los FIBDatasets, sólo se emplean de forma unidireccional, es decir llamados desde el Form y no al revés, por lo que podrían residir en el DataModule perfectamente. En cuanto a los DataSources, a veces sí son necesarios en el formulario para controlar ciertas acciones.

Ahora, como te dije, CnPack tiene la opción de ocultar y mostrar los componentes no-visuales. Simplemente basta el botón secundario y haces clic en "Show/Hide Non-Visual. Lo que hace eso simplemente es "transparentarlos", invisibles, los puedes seguir seleccionando si es que te lo preguntas.

Cuando dices transparentarlos ¿te refieres al efecto que aparece en las imágenes que puso Egostar?   

Saludos

[Marc]

Hola Marc,
Se ve bastante bien de pinta la aplicación 

Gracias   

No te digo que necesariamente sea un mal diseño... únicamente trato de invitarte a pensar si es tan, pero tan necesario llegar a esos extremos.
Se que en los sistema de gestión, y sobre todo en aquellos en los que se hasta pretende controlar y administrar la cantidad de desperdicio fecal del empleado con su respectivo informe semanal y el de auditoría para controlar que realmente el momento del baño dice ser el que és y ¡que decir de esos raros informes en que se busca relacionar la cantidad de idas y los kilos dejados con la calidad de atención y los ciclos lunares! se puede llegar fácilmente a pantallas que no tienen un hueco libre.

Esta es mi cruz. Mi socio, Francisco, es de estos.   

A veces pienso que el tamaño del monitor ha seguido creciendo en cuanto a la demanda de más cosas para llenar en un form. 

 

¿Realmente vale la pena inundar los forms de cosas? Hay usuarios y usuarios... y para mi debe hacerse un esfuerzo en equilibrar la densidad de controles en un form respecto a la cantidad de forms en la aplicación. No estaría demás considerar algo de ergonomía visual ¿no crees?
No es tan molesto tener que abrir dos o tres forms.... distinto es si tiene que abrir 5 o más para hacer una cosa.

Sí, es difícil mantener el equilibrio entre usabilidad, ergonomía, optimización del código, densidad de controles, ....

Solo quería mostrar como no es tan descabellado lidiar con formularios con más de 100 componentes no visuales (y en esa aplicación hay unos cuantos formularios más, como este).

[Marc]

Antes que nada se ve chula la aplicación  , y tampoco creo que esté muy recargada de controles, creo que utilizas los normales en una aplicación de estas características, incluso los Ribbon de la parte superior me parecen decentes y apropiados (digo esto porque le cogí manía a los Ribbon que traen aplicaciones del MS Office, que a mi entender recargan demasiado la pantalla con tanta opción y tanto dibujito).

Gracias (y te entiendo bien, sobre el Ms-Office).

En cuanto al diseño, muchos de los no-visuales que hay en el formulario son de acceso a datos ¿no se podrían mover a un DataModule? Es temerario proponer esto, ya que sólo tú sabes cómo los manejas y cómo interactúan con el formulario, pero quizás algunos -estoy pensando en los FIBDatasets, sólo se emplean de forma unidireccional, es decir llamados desde el Form y no al revés, por lo que podrían residir en el DataModule perfectamente. En cuanto a los DataSources, a veces sí son necesarios en el formulario para controlar ciertas acciones.

La verdad es que me daría mucho coraje tener que hacer eso. 

Ya utilizo DataModules, pero solo cuando creo que es pertinente. Por ejplo, el DataModule general con la conexión a la base de datos y otros Datasets muy utilizados, o bien el DataModule de impresión de Facturas (contiene los Datasets y componentes FastReports para la impresión de Facturas, está en un DataModule porqué puedo tener que imprimir Facturas desde el formulario de Factura, desde la Gestión de Facturas, desde la ficha de Cliente, etc ...), etc. ...

Pero me da coraje tener que poner un DataModule a cada Formulario de datos (un centenar de formularios). Sobretodo porqué esos componentes solo son usados desde el formulario, por lo tanto no hay ninguna razón para esa separación que estrictamente la comodidad visual durante el desarrollo (no tener los componentes molestando encima de los controles). Hago aplicaciones de dos capas, tradicionales, el tratamiento de datos está íntimamente ligado con la interficie de usuario (si tuviera una capa adicional de reglas de negocio, entonces sería otra cosa, pero nunca me ha acabado de convencer ese paradigma, me da la impresión que es demasiado trabajo adicional para muy poco beneficio).

Como el tratamiento de datos está tan ligado a la interficie, poner Datamodules separados para los formularios (cuando es dificilmente justificable debido a que esos componentes solo son usados por ese formulario), me parece mucho incordio (¿ he dicho ya que soy un programador perezoso ?    ) . No es solo que en tiempo de ejecución vas a tener que ligar los 23 datasources que hay en ese formulario, es que hay muchas relaciones bilaterales entre ambos que tienes que enlazarlas en tiempo de ejecución (por ejplo, al abrir el Dataset principal, hago visibles o invisibles algunos controles en función de los datos de ese registro, eso significa que el DataModule tendría que acceder directamente a los controles del formulario), etc. ...

Mucho trabajo, soy demasiado perezoso para cambiar a algo que me complique la programación y no lo vea justificado con suficientes beneficios.   

Ahora, como te dije, CnPack tiene la opción de ocultar y mostrar los componentes no-visuales. Simplemente basta el botón secundario y haces clic en "Show/Hide Non-Visual. Lo que hace eso simplemente es "transparentarlos", invisibles, los puedes seguir seleccionando si es que te lo preguntas.

Cuando dices transparentarlos ¿te refieres al efecto que aparece en las imágenes que puso Egostar?       

Saludos

Cuando le das a un botón, desaparecen los componentes no visuales (como si nunca los hubieses añadido al Form). Puedes trabajar sin tenerlos en medio, molestando, y cuando vuelves a darle al botón, reaparecen.

Egostar consigue lo mismo, moviendo el borde inferior del formulario en tiempo de diseño, de forma que los componentes no visuales quedan visibles o invisibles, dependiendo de donde pongamos ese borde. Pero yo no puedo utilizar ese sistema, ya que prácticamente todos los formularios los hago escalables (con los Anchors), de manera que cuando muevo el borde inferior, también se re-escalan y mueven los controles del formulario, así que de cualquier forma siempre tendría los componentes no visuales, molestando, encima de controles del formulario.