Diseño en Bind Visually

[jafera]

Buenos días a todos.


Estoy migrando una aplicación mía personal desde VCL a FMX, prácticamente la estoy reescribiendo de cero.
El problema es que el form principal tiene varias pestañas y un montón de edits, combos, checks, etc.
He creado diferentes layouts en el bind visually para que solo vea los spaghetis de cada pestaña y no sea una maraña y he notado una lentitud aterradora en el diseño, es normal?
Supongo que no soy el único que tiene una aplicación con muchos componentes en pantalla.
Tal vez hay algún otro sistema para que esta ralentización no sea tan "visual"?


Os paso una imagen de muestra

Gracias

[Neftali [Germán.Estévez]]

Supongo que una opción sería diseñar Frames (o forms) separados y luego "juntarlos" (dockarlos) en ejecución.
te obligará a generar más código para "conectarlos" en ejecución, pero se podría probar.

[jafera]

Gracias Germán.


Te refieres a crear forms separados uno por pestaña?
Es que ahora la información principal esta en una sola tabla básicamente a parte de las tablas auxiliares.

Saludos

[Neftali [Germán.Estévez]]

Empezado por jafera

Te refieres a crear forms separados uno por pestaña?
Es que ahora la información principal esta en una sola tabla básicamente a parte de las tablas auxiliares.

Si un Frame/form por pestaña.
En ejecución (antes de abrir los Datasets) los incrustas (dockas) y les pasas como propiedad la fuente de datos (Dataset).
No debería haber problema porque todos apunten a la misma tabla. Una vez que todos estén dockados y apuntando al Dataset correcto ya puedes abrirlo.

[emailx45]

1) No conozco la cantidad ni el tamaño de los campos, pero ten en cuenta que, al usar LiveBinding, estás empleando RTTI de forma implícita. ¡Por lo tanto, todo se procesa ante cada cambio en el estado de los valores!
2) LiveBinding es excelente para ciertos escenarios, pero una pesadilla para otros (quizás sea tu caso; todo depende de cómo lo implementes en tu código).
3) Con tablas pequeñas y un volumen de datos reducido, el rendimiento es bueno. Si estos aumentan, ¡es probable que el rendimiento disminuya!
4) No es habitual que los usuarios necesiten tener 100 campos de datos en una misma pantalla; de hecho, dependiendo de la cantidad de información, ¡queda claro que no es lo ideal!
5) En el caso de formularios de respuesta —donde hay una pregunta y varias opciones—, solemos modularizar el diseño dividiéndolo en formularios más pequeños. Por ejemplo, utilizando pestañas o subformularios, según sea necesario.
6) Sin embargo, esto no garantiza que el rendimiento de LiveBinding mejore, ya que el volumen total de información sigue siendo el mismo. Modularizar implica «dividir» las tareas, lo cual está directamente relacionado con la cantidad de campos en el registro.
7) Para mitigar la pérdida de rendimiento al usar LiveBinding, la mejor opción es recurrir a la codificación manual, eliminando así por completo el uso de RTTI. Puede parecer un paso atrás, ¡pero no lo es! ¡De hecho, es mejor! ¡Haz la prueba y verás!
8) Si consideras que esto supone un retroceso y no es una opción, intenta dividir tu consulta (query) en porciones de datos más pequeñas y trabaja con pestañas o subformularios.
9) Ten en cuenta que utilizas más de un LiveBinding Source; por lo tanto, multipliquemos esto por la cantidad de campos y el tamaño de la información contenida en ellos. A esto, sumemos las consultas automatizadas del RTTI a la información en memoria, junto con la complejidad que tu propio código añade para que todo esto se refleje en la pantalla. Luego, agreguemos algunos ciclos de CPU adicionales necesarios para mostrar los resultados en la interfaz de usuario (UI). Al final, observa el resultado del uso indiscriminado de LiveBindings.
10) Cada persona tiene su propia opinión, ¡incluso cuando tiene el cuello sobre el filo de la cuchilla!