[Xojo 2025r3] Bienvenido a la Rejilla

Xojo 2025r3 introduce la primera iteración del control DesktopGrid. Se trata de uno de los controles más solicitados, permitiendo mostrar tantas filas y columnas como puedas necesitar para el propósito de tus apps de escritorio. Veamos algunas de sus capacidades.

Tal y como ocurre con otros controles del framework de Xojo, DesktopGrid utiliza una fuente de datos (DataSource) para obtener la información que ha de mostrar en las celdas, entre otras operaciones. Esto significa que, en vez de añadir las celdas, filas o columnas tal y como harías con ListBox, será la propia instancia de DesktopGrid quien esté a cargo de preguntar sobre la información que precise para su funcionamiento al elemento o control de Xojo encargado de implementar la interfaz de clase GridDataSource. Estas son algunas de las ventajas a la hora de utilizar este enfoque:

• Celdas basadas en ContainerControl. Las celdas del DesktopGrid son los ya conocidos ContainerControl con los que ya estás habituado a usar. De modo que podrás utilizar el mismo diseño de ContainerControl para todas tus celdas, o bien diferentes ContainerControl para cada celda, fila o columna. Eso depende de tí, y de cuales sean las necesidades de la información a mostrar. También significa que todas las celdas representarán controles activos y actuarán como tales.

• Mejor gestión de la memoria. Las instancias DesktopGrid sólo mantendrá “vivas” aquellas celdas que realmente deban mostrarse en pantalla; lo que redunda en una mejor gestión del recurso de memoria del ordenador, especialmente cuando se trate de mostrar un elevado número de celdas. Por ejemplo, cada vez que cambies el tamaño de la ventana que contenga una instancia de DesktopGrid, esta solicitará a su DataSource por más contenido… sólo si es necesario. Una vez que los límites de las celdas queden fuera de los propios límites (ancho x alto) de la instancia DesktopGrid… los ContainerControl de las celdas correspondientes se cerrarán, de modo que tu código pueda reaccionar a dicho evento; además de que la memoria que estuviesen utilizando quedará liberada.
• Mejor rendimiento. Cuando se trabaje con un número realmente elevado de datos (celdas), estas no se pre-cargarán en el control… lo que significa que la ejecución de la app o bien la presentación de la ventana que contenga la instancia de DesktopGrid será prácticamente instantánea.

• Flexibilidad de representación. Dado que la cantidad de filas y columnas es proporcionada por el DataSource, resulta más fácil ajustar el modo de representación de celdas y columnas del DesktopGrid para que se comporte como un diseño “flexible” en función, por ejemplo, del ancho disponible para el control. Además, también es posible utilizar diferentes anchos para cada una de las columnas, mientras que la altura de las filas se mantendrá en todo caso como un valor fijo.

• Cambio en la representación de datos “sobre la marcha”. Dado que el DataSource es el responsable de proporcionar el contenido para cada celda, es posible cambiar la representación (diseño del ContainerControl) sobre la marcha… o incluso recuperar los datos propiamente dichos desde una fuente de datos diferente.
• Mejor separación de responsabilidades. Si bien es posible implementar los métodos de la interfaz de clase GridDataSource en la propia instancia de DesktopGrid o incluso en la ventana que lo contiene, el hecho de tener una clase dedicada para tal fin resulta un mejor enfoque. Esto implica una mejor separación de responsabilidades entre la vista, el modelo (los datos que se mostrarán en las celdas), y también el controlador a cargo de gestionar las operaciones entre el modelo y la vista. Incluso en dicho caso podrás utilizar el mismo DataSource para gestionar varias instancias de DesktopGrid.
• Cabeceras a tutiplén. Las instancias de DesktopGrid mostrarán por omisión las cabeceras correspondientes a las filas y a la columnas. Esto es algo que puedes cambiar utilizando el Panel Inspector asociado con cada instancia de DesktopGrid o bien mediante código. En muchos casos, resulta útil que se muestren las cabeceras… mientras que en otros probablemente prefieras mantener ambos tipos de cabeceras visible o bien las correspondientes a las filas o las columnas. En cualquier caso, es un ajuste que también podrás modificar sobre la marcha en tiempo de ejecución.En este sentido, el contenido que se muestra por omisión en las cabeceras será el típico: la numeración de cada columna y fila; pero también es posible personalizarlo tanto como desees mediante los métodos PaintHeaderContentForColumn y PaintHeaderContentForRow, correspondientes a la interfaz de clase GridDataSource.

¿Es DesktopGrid un sustituto de DesktopListBox?

Por supuesto, puedes saltar al vagón del control DesktopGrid para cualquier propósito que puedas tener; pero no es un substituto de DesktopListBox en muchos escenarios. Por ejemplo, si la información a mostrar es simplemente textual (como el uso de una simple Label) o basada en el tipo de capacidades que ya soporta DesktopListBox (como por ejemplo la representación jerárquica de información), entonces el DesktopListBox es lo que deberías de continuar utilizando.

DesktopGrid está más orientado a aquellos escenarios en los que precises mostrar diseños más complejos en cada celda utilizando controles activos (no la representación temporal como una imagen de los mismos, o cualquier otro “truco” por el estilo); o bien cuando cada celda precise mostrar su propio diseño (combinación de controles activos), incluyendo por ejemplo el uso de instancias de ListBox entre ellos.

Algunas consideraciones de rendimiento a tener en cuenta

Si bien esta es la primera iteración del control DesktopGrid, hemos mantenido nuestros esfuerzos en su rendimiento durante todo el proceso, pero existen algunas consideraciones que pueden impactar en el rendimiento de su redibujado. El más significativo es que, dado al hecho de que se utilizan controles activos para cada celda, el rendimiento será el mismo que obtendrías si tuvieses la misma cantidad de controles en el diseño de una ventana estándar. Obviamente, podríamos haber utilizado otras técnicas, como por ejemplo celdas reutilizables o bien la representación como imagen de las celdas mostradas, pero cada uno de estos enfoques tienen sus propias desventajas.

Como regla general, especialmente cuando el control de rejilla ha de trabajar con una gran cantidad de celdas, el rendimiento dependerá del tamaño de la celda propiamente dicha, así como de la cantidad de celdas que deba mostrar simultáneamente en el tamaño de control disponible (columnas x filas). Si ha de mostrar una gran cantidad de filas y columnas en el área visible, y el tamaño de las celdas es simplemente una etiqueta… el rendimiento de redibujado será inferior; además de que este también dependerá del propio sistema operativo sobre el que se esté ejecutando la app (e incluso la versión del sistema operativo propiamente dicho, en algunos casos).

Conclusiones

Si bien se trata de la primera iteración del control DesktopGrid, ya estamos trabajando en la siguiente batería de características para dicho control, además de continuar puliendo las ya existentes. En ese sentido, queremos dar un sincero GRACIAS a todos los que habéis proporcionado vuestros comentarios e ideas, así como vuestro preciado tiempo, durante el ciclo beta para probar el control DesktopGrid (¡vosotros sabéis quienes sois!). Vuestros comentarios siempre son valiosos, y las solicitudes de características realizadas (sumadas a las que ya estaban previstas) se verán reflejadas para lograr que el control DesktopGrid cumpla mejor con vuestras necesidades.