Formulario QML
Última actualización
Última actualización
Se trata de un objeto de proyecto de aplicación que sirve para presentar datos de un registro de una tabla, en un modelo programado en lenguaje QML. Para crear un objeto de este tipo seleccionar la opción nuevo objeto/formulario QML del menú objetos de Velneo vDevelop o a través de la galería de objetos.
Las propiedades de un formulario son:
Etiqueta alfanumérica que identifica de forma unívoca un objeto dentro del proyecto de aplicación. Este identificador será el que usemos para referenciarlo en otras propiedades de otros objetos.
El identificador constará de mayúsculas y números exclusivamente. Al identificar de forma unívoca un formulario no puede haber duplicidad.
Etiqueta alfanumérica que servirá como descriptor del formulario QML. Se usará para presentar información del formulario en objetos y en los inspectores.
Podemos definir una etiqueta por cada idioma presente en el proyecto.
Podemos definir los estilos:
Limita el acceso del usuario final al objeto desde puntos donde no se haya programado el acceso al mismo.
Permitirá establecer una relación de herencia inversa con un objeto de un proyecto que hereda el proyecto actual. La activación de este estilo hará que el formulario no pueda ser editado ya que su contenido será establecido en el proyecto heredado por éste. Ver el capítulo relativo a sub-objeto inserción para ampliar información al respecto. Un formulario con este estilo activado se distinguirá visualmente en el panel de proyectos por usar una tipografía cursiva en su identificador:
El sistema de bloqueos por defecto en formularios es el bloqueo blando, esto quiere decir que si dos usuarios editan la misma ficha, modifican y aceptan cambios, si no hay colisión (es decir, si han modificado campos diferentes) se fundirán las modificaciones de ambos. Si hay colisión, es decir, que modifican un mismo campo, el valor que mantendrá la ficha en ese campo será el del usuario haya guardado la ficha en último lugar. Por el contrario, el bloqueo duro implica que se bloqueará el registro editado en el formulario, provocando el inicio de una transacción y lo bloqueará en exclusiva en modo lectura/escritura hasta que finalice la transacción, por lo que no podrá ser modificado por otros usuarios mientras el formulario esté abierto. Es fundamental conocer las implicaciones derivadas del bloqueo duro, por lo que es aconsejable leer detenidamente el capítulo dedicado al sistema de bloqueos de Velneo vServer.
Nota |
Si usamos un formulario con bloqueo duro como dock el registro editado en el mismo permanecerá bloqueado todo el tiempo ya que, aunque se cierre el dock, el formulario sigue abierto pues cuando cerramos un dock no cerramos el objeto contenido en él sino que lo ocultamos. |
Permite omitir la barra de título de la ventana. Solamente funcional en cuadros de diálogo.
Permite omitir el menú de sistema de la ventana.
Permite ocultar el botón maximizar de la ventana.
Permite ocultar el botón minimizar de la ventana.
Permite ocultar el botón de cierre de la ventana.
Esta propiedad nos permite documentar el uso del formulario.
Tabla de un proyecto de datos heredado cuyos registros van a ser creados, modificados o visualizados en el formulario.
En este parámetro seleccionaremos el fichero de script que contenga el código QML que deseamos utilizar. En la ventana de selección del fichero a asociar al control podemos activar la opción aplicar macros. Si se activa lo que se hace es sustituir el id_ref de proyecto por la macro (CurrentProject). De esta forma, cuando movamos el script y el objeto ficha QML de un proyecto a otro, la referencia se conservará gracias a la macro, apuntando al fichero correspondiente buscándolo en el proyecto en curso.
En esta propiedad especificaremos el modo en el que será redimensionado el contenido del objeto en función del espacio disponible en la pantalla. Los valores posibles son:
El contenido del control donde se use este objeto se redimensionará según se haya especificado en el código QML.
El contenido del control donde se use este objeto se expandirá/contraerá según el espacio disponible.
Los valores posibles son:
El formulario se presentará en forma modal, bloqueando el interfaz en primer plano.
El formulario se presentará en forma de vista, como una ventana más del interfaz, en función del sistema de ventanas seleccionado.
Es un reloj que permitirá ejecutar automáticamente uno o varios eventos declarados en el formulario de forma periódica. En este parámetro se indicará el tiempo, en milisegundos, para cada iteración del timer. Si el valor es 0, querrá decir que no se activará el timer.
Los AuxModels o modelos auxiliares nos permitirán declarar modelos, para trabajar con listas.
Las propiedades es este sub-objeto son:
Etiqueta alfanumérica que identifica de forma unívoca al objeto dentro del proyecto. Este identificador será el que usemos para referenciarlo en otras propiedades de otros objetos.
El identificador constará de mayúsculas y números exclusivamente. Al identificar de forma unívoca un objeto no puede haber duplicidad.
Etiqueta alfanumérica que servirá como descriptor del objeto. Se usará para presentar información del objeto en otros objetos y en los inspectores.
Podemos definir una etiqueta por cada idioma presente en el proyecto.
Podemos definir el estilo privado que limita el acceso del usuario final al objeto desde puntos donde no se haya programado el acceso al mismo.
Esta propiedad nos permite documentar el uso del sub-objeto.
En este parámetro indicaremos el nombre que usaremos para referenciar al modelo dentro del código QML.
En este parámetro indicaremos el modo en el que este modelo auxiliar se sincronizará con el modelo principal. Los valores posibles son:
Se definirá dentro del código QML cuándo se cargará el modelo auxiliar.
Al cargar el formulario, se cargarán todos los modelos auxiliares. Esta opción, por tanto, puede penalizar la carga del objeto si se trata de listas grandes.
En este parámetro declararemos el proceso que alimentará el auxModel. El proceso podrá tener como entrada: una ficha o una lista de la tabla asociada al theListModel o sin origen, y como salida una lista de la tabla que queramos asociar al auxModel.
En este parámetro, mediante una fórmula especificaremos la cadena de texto a presentar por cada elemento del modelo auxiliar, que en el código html estará declarado con la etiqueta display.
En el código QML Se declarará un elemento Text con el source: display para incluir el texto especificado en esta propiedad.
En este parámetro, mediante una fórmula compondremos la url de la imagen a presentar por cada elemento del modelo auxiliar, junto con el texto, que en el código html estará declarado con la etiqueta decoration.
En QML, en las fórmulas de url imagen, referenciaremos las imágenes siguiendo la estructura siguiente:
"image://velneo/?/ALIAS_PROJECT/IDOBJETO/[DATO]"
El carácter marcado con ? puede ser:
D – dibujo: "image://velneo/D/ALIASPRO/IDOBJETO"
I – Icono de tabla estática: "image://velneo/I/ALIASPRO/IDTABLAEST/Campo"
C – Campo objeto dibujo: "image://velneo/C/ALIASPRO/IDTABLA/Campo"
En un formulario QML podemos mostrar campos objeto dibujo de la tabla asociada al objeto, pero no de otras tablas relacionadas.
Un ejemplo de fórmula de url imagen para QML podría ser:
Campo objeto dibujo de la ficha en curso o un dibujo si el campo está vacío.
O bien con el id del fichero:
En el código QML se declara un elemento Image con el source: decoration para incluir la imagen de esta propiedad del objeto Lista QML.
El QML para resolver las imágenes a incluir necesita una senda que puede ser a una fichero o en disco o una URL para que sea servida por un servidor. Cuando lo hacemos para tablas en disco en la fórmula le damos una URL que resuelve vServer que es el encargado de devolver la imagen al QML, sin embargo estoy no es posible hacerlo con tablas en memoria, ya que no disponemos de un servidor que pueda procesar dicha URL, la alternativa pasa por exportar las imágenes de la tabla en memoria a disco y alimentar el QML con las sendas apropiadas para que QML pueda leer las imágenes de disco.
