BLOG

Rejilla de base de datos 7.15

Por cperez el | 8 Comments

Importantes novedades en rejilla y rejilla editable
El objeto más usado en nuestras aplicaciones para mostrar listas de datos es, sin duda, la rejilla. Por este motivo cualquier mejora que se produce en este objeto cobra vital importancia para nuestros desarrollos.

En la versión 7.15 la rejilla ha recibido una profunda revisión donde la mayoría de las mejoras no tendrán una repercusión visual en la interfaz, pero sí las notarán los usuarios de nuestras aplicaciones cuando la usen o los desarrolladores cuando programen con el objeto. Las mejoras afectan tanto a la rejilla editable como en modo visualización. Vamos a repasar todos esos pequeños grandes detalles que nos ayudan en nuestro día a día:

Edita el contenido de las columnas con el editor que prefieras
Hasta ahora, al definir una columna editable no podíamos asignar cómo se representa visualmente su editor, asumiendo un valor por defecto. A partir de esta versión podemos seguir dejando el editor por defecto o declarar en la propiedad “tipo editor cuerpo” cuál queremos que utilice el usuario, como vemos en la imagen.

rejilla editable

Gracias a este nueva propiedad, nuestras rejillas editables ganan en usabilidad, funcionalidad, velocidad y estabilidad.

Data catcher edit en rejillas
En esta versión ha aparecido un nuevo y potente control de edición llamado data catcher edit. Hemos incluido este control dentro de los que puedes seleccionar para usar en la edición de cualquier columna, añadiendo más funcionalidad en la edición de datos en rejilla.

data catcher en rejilal editable

Define el alto de las cabeceras de rejilla
Si en la propiedad “alto de cabecera“ dejas el valor 0, se asume que la configuramos en modo automático y se creará con un alto de cabecera estándar preestablecido para el control. Si lo deseas, puedes aplicar el valor que te interese para hacerla más grande o pequeña, con el objetivo de ajustarla a tus intereses de interfaz, o incluso hacerla multilínea.

alto cabecras rejilla

En la migración de versión la propiedad se pone a 0, es decir, en modo alto automático.

Las rejillas ahora también tienen propiedad y señal “timer”
Al igual que ocurre con otros objetos, ahora ya puedes declarar la propiedad “timer” en la rejilla y gestionar la señal para ejecutar manejadores de evento. Esto te permite programar automatismos directamente en la rejilla, tanto si está incrustada en un formulario con si está en modo vista.

timer en rejillas

Ya puedes usar el comando “interfaz: establecer foco” en columnas
Puedes usar el comando de instrucción “interfaz: establecer foco” con las columnas de la rejilla, lo que te permite gestionar saltos del foco entre columnas en función de las condiciones de edición que desees.
Nuevas señales de edición pre-aceptada y edición pre-cancelada

Es en estas nuevas señales donde puedes utilizar el comando de instrucción “Set retorno proceso = NO” para evitar que se acepte o cancele la edición. También es en estas señales donde puedes utilizar el comando de instrucción “interfaz: obtener la ficha en edición de la rejilla” ya que en este punto la edición sigue activa. La señales edición aceptada y edición cancelada se ejecutan con posterioridad a que se acepte o cancele la edición.

Las columnas de la rejilla editable emiten la señal “value changed”
Esta nueva funcionalidad nos permite, de forma sencilla, gestionar cuándo el usuario ha modificado el valor de alguna de las columnas de la rejilla.

Es funcional la variable EVENT_PARAMS para señales de ítem
Hemos incluido la actualización de valores de la variable EVENT_PARAMS para las señales item-activado, item-clicked, item-doble-clicked y itemSelChanged, devolviendo en el primer valor del array la línea de la rejilla en la que se produce el evento.

Mejorando lo ya existente
Además de las novedades incluidas en esta versión de la rejilla y rejilla editable hemos realizado un notable esfuerzo en pulir todos esos pequeños o grandes detalles de este objeto para que te ayuden a crear mejores interfaces. A continuación te detallamos algunas de las correcciones y mejoras realizadas:

  • Hemos revisado por completo el sistema de señales del objeto y sus subobjetos.
  • En edición ”si se produce un error en el alta” ya no permanece una línea en blanco, evitando la necesidad de refrescar la rejilla.
  • Se han resuelto los problemas que se producían en algunas rejillas editables que combinaban columnas editables con otras no editables, ahora ambos tipos de columnas se llevan bien durante la edición.
  • Se han solucionado los problemas relacionados con las altas en rejilla editable.
  • Se ha mejorado el uso de los iconos de tabla estática así como su combinación con texto en la misma columna.
  • Se ha mejorado el uso de la tecla “Tab” en los controles que combinan ventana de edición y botones.
  • Ahora en el editor de rejillas la función ancho de título (Alt+F7) calcula bien el ancho teniendo en cuenta que las cabeceras se ponen en negrita, y también lo hace correctamente con texto pequeños.
  • La función setCurrentSelect(Int) de las clase VAbstractListDataView, pasándole un parámetro entero con la posición del registro, ya funciona correctamente.
  • En la rejilla editable ahora se dispara correctamente la señal de edición aceptada si estando en edición hacemos clic con el ratón en una columna no editable, además ahora  también se dispara correctamente si estando dentro de edicion se cambia el foco fuera de la rejilla, por ejemplo, haciendo click en otro control.
  • Se ha subsanado la incidencia que producía que no se ejecutase el subproceso del comando “interfaz: obtener la ficha en edición de la rejilla” en un evento disparado con las señales edición aceptada y edición cancelada.
  • En vDataClient al visualizar la rejilla de una tabla ya se muestran las columnas correspondientes a punteros singulares o hermanos, aunque estén en las últimas posiciones de la lista de campos.
  • Subsanada la incidencia que producía que en una rejilla con totales de suma acumulada, con una columna que muestra un campo puntero a maestro, cuando hay registros que contienen códigos inexistentes en el maestro, la rejilla recalculaba constantemente totales. Ahora sólo se calculan los totales una vez.
  • El pie de rejilla se ajusta correctamente cuando el pie activo es verdadero y con un modo de cabecera vertical, aunque cambie el ancho de la cabecera vertical.
  • Subsanada la incidencia que producía que al ordenar o invertir orden en rejillas, la multiselección no se ordenaba, con lo que quedaban seleccionados otros registros de la lista.
  • Mejorado el inspector de errores para que no rompa vDevelop al ejecutar el inspector de errores aunque haya una rejilla que tenga asignada una tabla que no existe y tenga declaradas columnas con campos de dicha tabla.
  • Aunque en los eventos de pérdida de foco no es recomendable mostrar mensajes, hemos evitado que, si se hace, rompa vClient al hacerlo en una columna de rejilla en edición.
  • Hemos conseguido evitar que se dispare la señal de pérdida de foco de la rejilla cada vez que una columna entra en edición.
  • Y otras muchas pequeñas correcciones de menor importancia… siempre pensando en la estabilidad y velocidad.

Velneo es el entorno ágil para el desarrollo
de aplicaciones empresariales

PRUEBA VELNEO

8 Responses to "Rejilla de base de datos 7.15"
  1. Buen día,

    Se comenta en el artículo

    Se han solucionado los problemas relacionados con las altas en rejilla editable.

    Serian tan amables de indicarnos cuales eran esos problemas en concreto, porque por el foro en dias recientes hemos estado opinando al respecto sobre el funcionamiento de las altas con doble click en rejillas editables, cuando si y cuando no.

    Gracias.

    Martin Ibarra.

    P.D. Si eso no esta considerado (no he probado la 7.15) valdría la pena la sugerencia de otro estimado colega e implementar su sugerencia en alguna próxima versión.

  2. [N1] cjribera dice:

    Concuerdo con lo que pregunta Martin. Cuando dicen ‘problemas relacionados con las altas’, se refieren a esto: http://soporte.velneo.es/entries/31279623-Permitir-insert-en-rejillas-editables ?

  3. [N1] cperez dice:

    Hola Martín y César,

    Estos son los problemas relacionados con las altas en rejilla a los que nos referimos:

    – En una rejilla editable, si hay error en el alta, la línea en blanco permanecía en la rejilla hasta que las refrescábamos.

    – Al dar un alta en una rejilla editable asignada a la propiedad Vista de datos de lista, el vClient se cierra.

    – En una columna de rejilla editable puntero a maestro ponemos vista de datos y en ejecución con menú contextual de la vista de datos si damos alta, rompe vClient.

    – En alta de nueva línea, en determinados casos al tabular en la última celda se crea una nueva fila pero no se inicia la edición y el cursor se ha perdido.

    – En una rejilla editable cuya primera columna está oculta (condición de visible a 0), al pulsar Insert se crea el registro pero no entra en edición.

    – Si la primera columna de una rejilla es editable pero su condición de visible no se cumple y pulso insert para añadir un nuevo registro se pierde el foco y la 1ª columna editable no lo gana hasta pulsar la tecla tab.

    Saludos

  4. [N1] cjribera dice:

    @cperez, Al menos yo, quede en las mismas, porque veo que la respuesta dice lo mismo que el mensaje original.

    Yo no tengo la 7.15, entonces, lo que necesito saber (y probablemente el colega Martin necesite lo mismo), es si el problema especifico que se menciona en esta idea http://soporte.velneo.es/entries/31279623-Permitir-insert-en-rejillas-editables, esta resuelto en la 7.15 (al menos allí aparece como idea no resuelta).

    ¿Como ha quedado entonces lo que se trata en la idea (alli se habla del click derecho, pero en el hilo mas se hablaba del alta con doble click en rejillas editables)?

    Gracias de antemano por la aclaración.
    Saludos
    Cesar

  5. Hola César,

    La idea no se incluyó en los desarrollos de la 7.15 ya que hay alternativas con las actuales funcionalidades (basta 3 líneas de código para crear una conexión de evento).
    En la 7.15 se ha puesto el foco en otros aspectos también muy interesantes y en ello hemos trabajado. Os invitamos a profundizar en ella… https://velneo.es/files/2014/04/Velneo-7.15.-Velocidad-y-Estabilidad_vs01.pdf

    Muchas gracias César!
    Saludos

  6. Hola Cperez,

    Si bien es cierto que con 3 líneas y un manejador de evento lo podemos “medio” solventar, la realidad es que NO es lo óptimo.

    Y cuando digo que no es lo óptimo me refiero a que aún cuando no se genera el alta indebidamente, en la rejilla que se muestra en pantalla SI se muestra un registro en blanco el cual no hay manera de quitar hasta que no se sale del formulario, eso para nada es “elegante” ni vá con la filosofía “life is soft” de V7.

    Amén de otros dos o tres comportamientos medio raros que observé (y que lamentablemente no documenté) al hacerlo así.

    Tiene razón Cesar y en ese aspecto lo apoyo completamente, hace falta que ese aspecto sea configurable desde las propiedades de la rejilla, que cuando se indique que será editable, activar o desactivar el alta con doble click mediante una propiedad, quedaría más elegante y acorde con “life is soft”.

    No sé si sea fácil o dificil el implementarlo, pero de que se agradecería no tengas la menos duda.

    Saludos.

    Martin Ibarra.

  7. Hola Martin.

    Los objetos, por defecto, deben tener en la medida posible un comportamiento estándar. En el caso de la rejilla editable, el mayor número de casos que nos encontramos al programar es que se permita el alta de registros sobre la rejilla editable, y ese es el caso que se contempla por defecto.

    La solución que se propone, poner una propiedad booleana, es excesivamente concreta y solo cubre un caso particular, el de “no quiero permitir altas en la rejilla pero si modificación”. En la realidad de la gestión empresarial del día a día las soluciones requieren resolver casos más complejos como que el alta no estará permitida para ciertos usuarios con determinados privilegios o que el alta estará permitida en función del estado que tenga el documento, etc.

    Por lo tanto la solución más sencilla para cubrir estos casos no pasa por poner un booleano o tener que aplicar una formula más o menos compleja, sino por el control sobre la edición que nos otorga atrapar la señal de edición iniciada.

    Aprovechando esa señal en el manejador debemos incluir cómodamente el código que necesitemos para determinar si queremos dejar o no seguir editando ese registro sea o no nuevo.

    Ejecutando el código que indico a continuación con la versión 7.15.1 (en la que se han resuelto diversas incidencias de rejilla editable, que está en fase de pruebas y que publicaremos en las próximas semanas) podrás comprobar que en la rejilla no queda ningún registro en blanco como indicas (y que pasa con la 7.15), sino que simplemente no se produce el alta, siendo su comportamiento el esperado.


    Interfaz: Obtener la ficha en edición de la rejilla()
    ____if (#ID = 0)
    ________Set retorno proceso = NO

    Creo que estas 3 líneas de código es una buena solución por su sencillez, pero sobre todo por la potencia que nos otorga a la hora de incorporar todos los controles que necesitemos en este punto. Personalmente, opino que resolver un caso no estándar con 3 líneas de código, sí lo considero una solución “Life is Soft” por ser rápida, sencilla de programar y flexible para añadir más potencia y control de las reglas de negocio.

    Un saludo.

  8. [N1] cjribera dice:

    Espero que de verdad se haya solucionado lo de los registros en blanco, que era la principal molestia en rejillas editables (algo inaceptable, que no se apega a ningún estándar y que recién el la 7.15.1 lo estan solucionado, tras varios años de tener el problema).

    Como dije en su momento en el hilo, todos estos años del problema (horas perdidas por N desarolladores y por la misma gente de soporte v7) se hubieran solucionado de raíz con la propiedad booleana, asi los que no querian alta con doble click, no tenían que lidiar con estos problemas que les creo v7 con la nueva ‘feature’.
    Un ejemplo, vean las horas hombres perdidas, solo en este hilo (y fueron unos cuantos con este tema, sin contar el chat-velneo). https://velneo.es/foros/topic/evitar-las-altas-en-rejillas-con-el-clic-derecho/

    ¿Todo por no implementar una propiedad booleana (o 2 que hubiera sido lo ideal) y los if respectivos?

    Inclusive no hubiera existido la necesidad actual de estar poniendo una conexión de evento y manejador de evento con las 3 lineas, a cada rejilla, lo que no deja de ser moroso, salvo que se use ‘guardar como’ que no siempre es aplicable (ademas, desvirtúa el uso de un almacén de objetos, que debería ser la forma por default y mas limpia de trabajar)..

Deja un comentario

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información. ACEPTAR

Aviso de cookies