Extendiendo Velneo con Maestro de extensión y Extensión de Ficha

Con este artículo iniciamos una serie dedicada a las diferentes posibilidades que tenemos de Extender Velneo, ya sea usando funcionalidades nativas de la herramienta o apoyándonos en objetos y tecnologías auxiliares como el visor html, javascript y qml.

Presentación

Me llamo Paco Satué y seguro que muchos me conocéis de los foros de Velneo. Me han ofrecido la oportunidad de escribir en el Blog y he aceptado encantado. Llevo ya siete años aprendiendo y programando con Velneo y no tengo duda de que es una buena herramienta para el desarrollo de nuestras aplicaciones de gestión, basadas siempre en datos organizados en tablas con relaciones entre ellas.Intentaré transmitiros a través del blog mis conocimientos y experiencia con el lenguaje, desde un punto de vista exclusivamente técnico, empleando una forma de contar las cosas lo más detallada posible, y pensando siempre que sois programadores de Velneo, algunos expertos y otros recién llegados.Inauguro mi participación en el blog con dos objetos, uno del proyecto de datos, el Maestro de extensión y otro del proyecto de aplicación pero integrado en los formularios como subobjeto, la Extensión de Ficha. Creo que son funcionalidades muy interesantes de Velneo y sin embargo muchas veces ignoradas, normalmente por considerarlas complejas de implementar o por desconocimiento.Voy a hacer un repaso de las características de ambos objetos y os mostraré algunos ejemplos de uso, que espero sean de utilidad para que los incorporéis con mayor confianza a vuestros diseños de bases de datos y formularios de edición.No me dejaré en el tintero comentar las incidencias que hay documentadas, que son varias y que habrá que conocer para sortearlas adecuadamente.

Descripción

La finalidad de los objetos Maestro de extensión y Extensión de Ficha es la misma, extender las posibilidades de nuestra aplicación para almacenar y mostrar datos extra, a partir de tablas que ya existen en el mismo u otro proyecto de datos. Los dos objetos pueden trabajar conjuntamente o de forma separada, el primero en la capa de datos y el segundo en el interface. Pasemos a enumerar los detalles.

Los objetos Maestro de extensión y Extensión de ficha también se denominan Tabla de extensión y Ficha de extensión respectivamente. En este artículo me referiré a ellos preferiblemente con la primera denominación, aunque pueden aparecer citados de la otra forma en vDevelop y en la documentación de Velneo.

Maestro de extensión para extender la capa de datos

El Maestro de extensión, también llamado Tabla de extensión, es una tabla de tipo maestra que solo puede existir si está asociada a otra tabla, llamada Tabla padre o principal, que debe existir previamente:

• entre el Maestro de extensión y la Tabla padre se establece una relación o enlace 1a1 a través del campo ID.
• la relación 1a1 padre-extensión es muy fuerte desde el lado derecho, es decir, no puede haber registros en el Maestro de extensión con ID nulo o cero.
• la relación 1a1 determina que un registro de la Tabla padre solo puede tener asociado un registro del Maestro de extensión.
• el resultado es que un registro de la Tabla padre se extiende con un registro del Maestro de extensión y ambos funcionan como uno solo.
• una Tabla padre puede tener varios Maestros de extensión relacionadas.
• la Tabla padre debe tener un campo ID único para establecer la relación 1a1, por lo tanto solo puede ser de tipo maestra normal o maestra arbolada.
• en la Tabla padre se crea un puntero virtual EXTENSION_ por cada Maestro de extensión que apunta al registro extendido. Este puntero nos permite acceder desde la Tabla padre, en tiempo de diseño y en ejecución, a los campos del registro extendido como si estuvieran en el mismo registro.
• los enlaces plurales de la Tabla padre también están disponibles desde el Maestro de extensión ya que comparten el mismo ID.
• con el asistente existe la opción de generar los índices complejos NAME, WORDS y PARTS que permiten localizar registros del Maestro de extensión por el campo NAME de la Tabla padre.
• la Tabla padre puede estar en el mismo proyecto de datos o en otro proyecto heredado.

En el esquema siguiente la Tabla padre Artículos se ha extendido con dos Maestros de extensión y mantendrá con ellos una fuerte relación 1a1 a través del campo común ID.

En la documentación podéis ampliar los detalles sobre las propiedades de las tablas de Velneo de tipo Maestro de extensión y el Asistente.

Extensión de ficha para extender el interfaz

La Extensión de ficha, también llamada Ficha de extensión, permite editar un registro diferente del asociado a la ficha principal del formulario, con la posibilidad de gestionar las operaciones de añadir, modificar o eliminar. Recordar que los campos de las tablas de los punteros maestros se muestran en el formulario en modo solo lectura.

• la Extensión de ficha es un subobjeto del formulario que añadimos desde la pestaña de Subobjetos (Ctrl+3).
• la Extensión de ficha extiende la funcionalidad básica del formulario, permitiendo visualizar y editar campos de otra tabla, añadiendo a la transacción una operación extra de Alta, Modificación o Baja.
• hay 2 modos de obtener el registro con la Ficha de extensión: mediante un puntero a maestro de la tabla principal del formulario o ejecutando un proceso que devuelva dicho registro. En los dos casos obtenemos una ficha que será editada conjuntamente con la del formulario.
• la aplicación inmediata de la Extensión de ficha es la de editar simultáneamente los campos de la Tabla padre y su Maestro de extensión.
• hay que tener claro que el formulario actúa sobre la ficha principal y es el subobjeto de Extensión de Ficha el que gestiona las operaciones sobre la ficha obtenida desde el puntero a maestro o desde el proceso.

Por lo tanto, es muy importante establecer el orden en el que deben ejecutarse las operaciones en la ficha principal del formulario y en la Extensión de ficha. Hay tres propiedades, una para cada operación de Alta, Baja y Modificación de la ficha principal. Indicamos mediante un valor numérico qué operaciones de la Extensión de ficha están permitidas y si se realizan antes (previo) o después de la operación principal. El valor numérico se obtiene del valor en binario representado por las 4 columnas de Modificación, Baja y Alta permitidas y si es Previa a la operación principal.Veamos dos ejemplos para verlo más claro.En el primer ejemplo el registro de la Extensión de ficha es un Maestro de extensión de la Tabla padre y tiene las operaciones de Alta, Baja y Modificación permitidas. Tendremos en cuenta que el Maestro de extensión no puede existir si antes no se ha creado el registro padre y no podemos dar de baja un registro padre que tenga un Maestro de extensión asociado. Con estas premisas los valores 2, 5 y 10 se obtienen de la siguiente manera:

• Cuando se produce un Alta de la ficha principal (Tabla padre), la Extensión de ficha se creará inmediatamente después (columna Alta = 1 y Previo = 0)
• Cuando se produce una Baja de la ficha principal (Tabla padre), la Extensión de ficha se elimina inmediatamente antes (columna Baja = 1 y Previo = 1)
• Cuando se produce una Modificación de la ficha principal, la Extensión de ficha se modifica si ha habido cambios (columna Modificación = 1) y si no existe se creará inmediatamente después (columna Alta = 1 y Previo = 0)

La tabla siguiente muestra esta implementación.

Es muy importante establecer estos valores correctamente para que el orden de las operaciones sea el adecuado, de lo contrario se pueden producir efectos indeseados. Por ejemplo, si el valor de Baja ficha principal fuera 4 (0100), la baja de la ficha principal se ejecuta primero, lo que no es posible por la integridad referencial ya que existe el Maestro de extensión, sin embargo inmediatamente después se realiza la baja de dicho Maestro mediante la Extensión de ficha. El vServer devolverá un error que puede confundir al usuario pensando que no se ha borrado nada. Lógicamente si el usuario vuelve a intentar el borrado, la operación se ejecutará correctamente.

Cambiemos ahora los papeles de la ficha principal y la Extensión de Ficha. El formulario edita directamente el Maestro de extensión como ficha principal y asociamos a la Extensión de ficha el registro de la Tabla padre.

• Cuando se produce un Alta de la ficha principal, la Extensión de ficha (Tabla padre) se creará inmediatamente antes (columna Alta = 1 y Previo = 1)
• Cuando se produce una Baja de la ficha principal, la Extensión de ficha (Tabla padre) nunca se elimina (columna Baja = 0)
• Cuando se produce una Modificación de la ficha principal, la Extensión de ficha se modifica si ha habido cambios (columna Modificación = 1) y la modificación se realiza inmediatamente antes (columna Previo = 1). En este caso el Maestro de extensión de la tabla padre debe existir siempre (columna Alta = 0)

Podéis comprobar en el vAdmin que las altas y borrados del registro principal del formulario se integrarán en la misma transacción que las operaciones de la Extensión de ficha. Sin embargo, las modificaciones del registro principal del formulario y las de la Extensión de ficha se ejecutarán en diferentes transacciones.

Las operaciones en la Extensión de ficha se realizan de forma automática y no disponemos de comandos que puedan modificar los campos del subobjeto. No existe un comando Modificar campo de Ficha de extension. Más adelante veremos un ejemplo de cómo solventar esta limitación.

En la documentación podéis ampliar los detalles sobre las propiedades de las Extensiones de ficha.

Navegando a la Extensión de ficha

En una relación "Tabla padre - Maestro de extensión" el formulario hace uso del enlace 1a1 para acceder a los campos de cualquiera de las dos tablas. Esta es una característica nativa de Velneo que nos permite navegar de una tabla a otra mediante los enlaces a maestro o plurales.Los controles del formulario que necesitan mostrar o editar información (propiedad Contenido) podrán acceder a los campos de la Extensión de ficha mediante la propiedad Ficha extension. Introduciendo en esta propiedad el identificador de la Extensión de ficha se habilitará en el editor de fórmulas el acceso a los campos de la tabla de destino.En la imagen siguiente el formulario de Artículos dispone de dos Extensiones de ficha FICHA_EXT_1 y FICHA_EXT_2, destinadas a editar los campos de los Maestros de extensión correspondientes. Disponemos de tres opciones para mostrar los campos de la Extensión de ficha: controles directos, control Vista de datos o Separador de formularios.

¿Y cómo navegamos por código?El enlace 1a1 se establece entre punteros de Maestros y por lo tanto usaremos los comandos de Lectura y Modificación de ficha de maestro. En la Tabla padre se crea un Puntero virtual al Maestro de extensión cuyo Identificador es de la forma EXTENSION_<ID del Maestro de extensión>. En el Maestro de extensión el campo ID es el puntero a la Tabla padre.En el esquema anterior:

• desde la Ficha de Artículos navegamos a la Extensión de ficha de la tabla de Artículos extensión 1 usando el comando:Leer ficha de maestro ( EXTENSION_ART_EXT_1 )
• y en el otro sentido desde la Ficha de Artículos extensión 1 navegamos a la Ficha de Artículos usando el comando: Leer ficha de maestro ( ID )

Los Manejadores del formulario pueden leer directamente los campos de la Extensión de ficha sin necesidad de navegar. Pueden acceder en modo Lectura a las Extensiones de ficha para asignar el valor de un campo del Maestro de extensión a una Variable local. El editor de fórmulas nos mostrará el árbol de campos de la Ficha activa y a continuación los campos de las Extensiones de ficha definidas en el formulario. En el código la doble almohadilla ## es el prefijo indicativo de la Extensión de ficha.Así mostrará el editor de fórmulas los campos de la tabla principal y las Extensiones de ficha.

Para leer el valor del campo CAMPO_EXT_11 y asignarlo a la Variable local CCAMPO_VALOR usamos el comando: Set (CCAMPO_VALOR, ##FICHA_EXT_1.CAMPO_EXT_11)

El identificador ##FICHA_EXT_1/2 funciona como un manejador de Registro del tal forma que podemos leer directamente cualquier campo del registro de la Extensión de ficha. Es una buena manera de disponer de un mecanismo de copia del contenido de los campos desde la Extensión de ficha a la ficha principal del formulario, usando el comando Modificar campo (NAME, ##FICHA_EXT.NAME), y sin necesidad de variable locales intermedias.

Herencia con Maestros de extensión

La Herencia es uno de los mecanismos más efectivos de Velneo y necesario para crear la extensión de una tabla mediante la relación 1a1. El usuario final verá la tabla y su extensión como una sola entidad gracias a la utilización de las Extensiones de ficha en los formularios.Extender una tabla maestra, mediante la herencia en varias aplicaciones y con distintas instancias de datos, puede tener implicaciones negativas en la integridad de la base de datos que habrá que contemplar para evitar problemas.Veamos un ejemplo a partir del esquema que estamos utilizando en el artículo.Queremos diseñar 2 aplicaciones distintas y que ambas se alimenten de la misma tabla de Artículos ART, por lo tanto heredamos vgestion_dat en cada proyecto de datos de las 2 aplicaciones. Una vez establecida la herencia ya se podrá extender la Tabla padre ART mediante una relación 1a1 usando los Maestros de extensión ART_EXT_1 y ART_EXT_2. A la hora de instanciar las 2 aplicaciones, la Tabla padre ART es común y se encuentra en la carpeta de datos vgestion_dat/ y cada aplicación instancia sus Maestros de extensión.

La relación 1a1 mantendrá la integridad referencial entre la Tabla padre ART y los Maestros de extensión, pero esta integridad se mantiene solo dentro de cada Aplicación. Desde la Aplicación 1 no se podrán eliminar artículos de la tabla ART que tengan Maestros de extensión en las tablas de la carpeta apli_dat_1, y desde la Aplicación 2 ocurre lo mismo con los Maestros de extensión de la carpeta apli_dat_2. Pero la Aplicación 1 no sabe nada de los Maestros de extensión de la Aplicación 2 y viceversa, por lo que desde la Aplicación 1 se pueden eliminar artículos de la Tabla padre ART que no tengan Maestros de extensión en su carpeta de datos y que sin embargo sí los tengan en la carpeta de la otra aplicación. En ese caso la integridad referencial de la Aplicación 2 se habrá roto ya que habremos dejado Maestros de extensión huérfanos.Por supuesto y como ya habrás deducido, la solución es diseñar las aplicaciones de tal forma que no puedan eliminar registros de la Tabla padre ART, o que exista algún mecanismo de supervisión que asegure la integridad referencial en todas las aplicaciones que la usen.En cualquier caso, la integridad referencial también hay que supervisarla para el resto de tipos de enlace entre tablas de diferentes aplicaciones e instancias.

La Herencia inversa

Ya sabemos que la Herencia inversa permite incrustar desde una determinada aplicación objetos de interfaz en los Formularios, Menús y Barras de herramientas de un proyecto heredado. Para el tema que nos ocupa, la herencia inversa usa el formulario de edición de la Tabla padre para incrustar en él los controles de edición de los Maestros de extensión.

Hay que aclarar que la Extensión de ficha se usa con formularios del proyecto principal de la aplicación y la Herencia inversa es necesaria cuando usamos formularios de un proyecto heredado. El objetivo de ambas funcionalidades es la misma, mostrar y/o editar conjuntamente los registros principal y Maestro de extensión.

La Herencia inversa no es automática, sino que debemos usar una característica especial denominada Inserción, que se compone de dos elementos, por un lado el Punto de inserción se crea en el proyecto heredado o de origen estableciendo la propiedad Estilos y por otro, el subobjeto de Inserción se añade al formulario del proyecto principal. En tiempo de ejecución, el formulario de la aplicación principal se muestra en el Punto de Inserción de la aplicación heredada usando el subobjeto Inserción.En la imagen siguiente el formulario FRM_EXT_ART_HINV pertenece al proyecto original de vgestion y las aplicaciones que lo hereden querrán insertar sus Maestros de extensión en la pestaña del separador de formularios que contiene el Punto de inserción.

El editor de vDevelop detecta automáticamente cuando la tabla insertada es un Maestro de extensión y en ese caso habrá la opción de mostrar botones de edición en la pestaña para añadir o eliminar el registro extendido.Los Puntos de inserción solo se pueden definir en formularios y acciones del proyecto de aplicación original. Esos formularios y acciones con Estilo Punto de inserción habrá que añadirlos a controles de tipo contenedor, como Separador de formularios, Pila de formularios, Menús y Barras de herramientas. Cada Punto de inserción puede recibir uno o varios objetos incrustados desde la aplicación principal.En la documentación podéis ampliar los detalles sobre la Herencia inversa y las propiedades del subobjeto Inserción.

Ejemplos de uso

Las tres principales razones, entre otras muchas, para usar Maestros o Tablas de extensión son:

• Extender o personalizar una tabla del proyecto heredado que no queremos o no podemos tocar.
• Integrar diferentes tipos de registros en una tabla, teniendo los campos comunes en la Tabla padre y cada tipo de registro en un Maestro de extensión.
• Reducir el tamaño de una Tabla padre trasladando los campos de poco uso al Maestro de extensión.

Una vez tengamos decidido cómo vamos a extender nuestras tablas y formularios, veamos algunos ejemplos de uso.

Personalizar los formularios de la Aplicación

Cuando desarrollamos aplicaciones desde una plantilla habrá muchos formularios que tendrán una parte común y otra personalizada. Por ejemplo, el formulario "Acerca de" mostrará datos desde la Tabla principal de la plantilla y datos de la Aplicación a través del Maestro de extensión.En la imagen siguiente el formulario FRM_EXT_ACERCA_DE es la plantilla, que será heredada por las dos aplicaciones. La plantilla muestra el campo #NAME de la Tabla principal y una Pila de formularios con un formulario de estilo Punto de inserción. Los formularios FRM_LOGO de cada aplicación usarán el subobjeto Inserción para incrustarse en la plantilla y mostrar el campo de dibujo con el Logo y el campo Name del Maestro de extensión.La Pila de formularios de la plantilla es útil en este caso para insertar formularios sin mostrar la pestaña del Separador. Cada aplicación es responsable de crear y tener disponible el Maestro de extensión con los datos de Logo y Name.

Formulario multi ficha

Los formularios de Velneo están diseñados para gestionar la transacción simultánea de una sola Ficha de entrada. Con las Extensiones de ficha se puede extender la edición simultánea a múltiples fichas de la misma o distintas tablas. Para ello seleccionamos en la Ficha de extensión el modo proceso, y escribimos el código específico que devuelve el registro que vamos a editar.Como ejemplo veamos un formulario, que partiendo de un artículo ID determinado, muestra dos Extensiones de ficha con el artículo de ID anterior y posterior respectivamente. Obtenemos así un formulario de edición con 3 fichas cuyas modificaciones se grabarán simultáneamente con el botón Guardar.Las Extensiones de ficha se han configurado para modificación, por eso las propiedades de Alta, Baja y Modificación tienen los valores 0,0,8. La propiedad Condición de activo de los controles con la Ficha de extensión es ##FICHA_EXT_1/2.ID > 0 para que solo sean accesibles cuando exista la Ficha de extensión.

Cuando pulsamos el botón Guardar se creará en el vServer una transacción por cada Extensión de ficha que haya tenido cambios, por lo tanto habrá entre 0 y 3 transacciones con una operación de Modificación.

Acceso a cualquier lista de Maestros

El formulario sin origen se puede extender para facilitar el acceso a Listas de registros de tablas maestras.Supongamos un formulario de Selección de Cliente que debe devolver el ID del registro de la tabla CLT. En el formulario la selección debe hacerse mediante un campo alfabético de enlace a maestro, el cual dispone de las propiedades Autocompletar y Vista de datos de lista. El formulario no tiene origen por lo que no se pueden usar controles de enlace a maestro y tampoco sirve usar un objeto ComboView del proyecto porque no tiene la funcionalidad de Autocompletado.La Extensión de ficha puede devolver una Ficha cualquiera si usamos el modo proceso. Con el uso de un proceso ya no necesitamos un puntero entre la tabla padre y el maestro, y podemos ejecutar cualquier código que devuelva una Ficha determinada.Para disponer de las Listas de maestros usaremos la técnica de definir una tabla en memoria que solo tiene campos punteros a maestro, y serán los maestros que vayamos a necesitar en los formularios de selección del proyecto.La tabla temporal TMP_LISTA_MAESTROS contiene los punteros a 6 tablas de maestros.

En este ejemplo diseñamos un formulario sin origen que permita la selección de un Cliente desde la tabla de maestros CLT. La Extensión de ficha ejecuta el proceso PRO_EXT_LISTAS con ficha de salida la tabla temporal TMP_LISTA_MAESTROS. Es un proceso vacío y su cometido es devolver una Ficha vacía a la Extensión de ficha. El resultado es disponer de un control de edición de puntero a Maestro con las opciones de Autocompletado y Lista desplegable.

El botón Seleccionar guardará en una variable local el ID seleccionado, obtenido desde la Extensión de ficha mediante el identificador ##FICHA_MAESTROS.

Introducir contenido a los campos de la Extensión de ficha

Cuando trabajamos con la Extensión de ficha solo podemos introducir contenido en los campos a través del Interface, no disponemos de comandos para hacerlo por código como un Modificar campo.Si necesitamos introducir datos mediante código tenemos que recurrir al API del Velneo. Para los campos numéricos disponemos de la función setValue(). En los campos de tipo alfabético la función setText() no funciona, pero podemos usar el objeto del portapapeles theApp.clipboard() que traslada el contenido de un campo a otro usando la función paste(). Los campos de edición a maestro son de la clase VBoundFieldEdit y lamentablemente no dispone de funciones para asignar un valor por código.El siguiente es el código javascript que copia valores de la Ficha principal del formulario a campos de la Extensión de ficha: // Copia valores de la Ficha principal del formulario
// a campos de la Extensión de ficha

// Controles de la Extensión de ficha
var oCtrFam = theRoot.dataView().control("CAMPO_FAM")
var oCtrExt1 = theRoot.dataView().control("CAMPO_EXT_11")
var oCtrExt2 = theRoot.dataView().control("CAMPO_EXT_12")

// Los campos Numéricos disponen de la función setValue()

// Para los campos alfabéticos debemos usar el
// Portapapeles porque setText() no funciona
var oClipBoard = theApp.clipboard()

// Copia el contenido del campo NAME al
// campo CAMPO_EXT_11 de la Extensión de ficha
oClipBoard.setText(theRoot.dataView().control("NAME").text)
oCtrExt1.clear()
oCtrExt1.paste()
oClipBoard.clear()

// Copia el contenido del campo REF al
// campo CAMPO_EXT_12 de la Extensión de ficha
oClipBoard.setText(theRoot.dataView().control("REF").text)
oCtrExt2.clear()
oCtrExt2.paste()
oClipBoard.clear()

// Los campos enlazados a maestro VBoundFieldEdit no
// funcionan, no disponen de paste()
// oCtrFam.paste()

Algunas incidencias a tener en cuenta

Los Maestros y Extensiones de ficha no se libran de las incidencias y bugs, y es conveniente conocerlas para que no afecten a nuestro código. Podéis consultar a soporte la lista actualizada de incidencias y calendario de resolución.Veamos algunas incidencias que pueden tener una solución alternativa.

Refrescar modificaciones del Maestro de extensión desde un manejador

Cuando modificamos el Maestro de extensión dentro de un manejador, la información se escribe directamente en el servidor, generando una transacción aislada que ya no podrá deshacerse. Normalmente el refresco terciario no funcionará porque los campos del Maestro de extensión se muestran a través del puntero virtual EXTENSION_ de la tabla padre.Para forzar el refresco en pantalla ejecutamos un segundo comando Modificar ficha de maestro que leerá el dato de nuevo desde el servidor. En el código siguiente el manejador copia el valor de la familia FAM al Maestro de extensión.Rem ( Modificar un campo de la Extensión de ficha )
Rem ( No se refresca en el formulario )
Set ( CFAM_COP, #FAM )
Modificar ficha de maestro ( EXTENSION_ART_EXT_1 )
Modificar campo ( FAM, CFAM_COP )
Libre
Rem ( Forzar el Refresco para leer el datos desde el vServer )
Modificar ficha de maestro ( EXTENSION_ART_EXT_1 )
Libre

Cambiar el identificador del Maestro de extensión

Cuando se modifica el identificador de un Maestro de extensión, en la tabla maestra cambia el ID del puntero a la extensión, pero no se refactorizan los sitios donde se usa dicho puntero. Normalmente debemos evitar siempre el cambio de identificadores de tabla.

Usar el comando Pedir formulario con Extensiones de ficha

Cuando modificamos por proceso un registro que tiene una Extensión de ficha con los comandos Modificar ficha seleccionada y Pedir formulario no se guardan las modificaciones de la extensión de ficha. El comando Pedir formulario no gestiona transacciones y por esa razón los cambios en la Extensión de ficha se ignoran. Por lo tanto, si queremos editar la Extensión de ficha no tenemos más remedio que usar formularios con evento Aceptar con gestión de la transacción y dejar el comando Pedir formulario para mostrar la Extensión de ficha en modo solo lectura.

Transacciones de alta y modificación de fichas con Extensiones de ficha

Podéis ver con el vAdmin las transacciones que se generan en el vServer. Es cierto que hay un comportamiento diferente con las transacciones en alta, modificación o borrado. Según el caso las transacciones aparecen agrupadas como una sola o separadas por tabla, lo que puede complicar la tarea de deshacer transacción.

Botón de menú en control de edición de maestro

Cuando en el Maestro de extensión existen campos punteros a maestro y los editamos con una Extensión de ficha, los botones de menú con los comandos Ficha: Localizar, Alta y Editar Maestro no funcionan ya que solo están operativos para la Ficha principal del formulario. Para superar esta limitación basta con editar el campo puntero a maestro dentro de una Vista de datos. Insertamos un control Vista de datos con la propiedad Ficha extension establecida para que podamos usar un subformulario con el campo de edición a puntero maestro y el botón de menú.

Conclusiones

He realizado una exposición completa de dos herramientas nativas disponibles en Velneo, destinadas a extender nuestras aplicaciones con funcionalidades que en un primer contacto con la herramienta pueden pasar desapercibidas. Espero que conceptos como Herencia inversa, punto de Inserción y enlaces 1a1 hayan quedado muy claros y que a partir de ahora los objetos Maestro de extensión y Extensión de ficha pasen a formar parte de vuestra lista de objetos preferidos.En próximos artículos seguiré explorando otras posibilidades de extender Velneo usando otros objetos y tecnologías auxiliares. Nos vemos en el foro.