27 Oct Las variables en Velneo

El tema de las variables en Velneo siempre ha suscitado dudas y algún que otro quebradero de cabeza, debido al mal uso de los planos de ejecución y del ámbito de las variables.

Recordemos el artículo ayudavelneo.com/el-peligro-de-las-variables-en-velneo-v7 para comprenderlo mejor.

En Velneo a Fondo hemos recopilado la información que hay dispersa en diferentes artículos y en la propia ayuda de Velneo y queremos preparar un artículo en el que podamos encontrar lo más interesante sobre el uso de las variables en nuestras aplicaciones.

Si crees que debemos añadir un concepto o idea nueva sobre las variables en Velneo no dudes en comentarlo.

Tipos de variables en Velneo

Las variables en Velneo V7 son objetos que permiten almacenar datos individuales. Hay dos tipos: las variables globales y las variables locales.

La variable global es un objeto del proyecto de datos, cuyo contenido es global a la aplicación y común, en el ámbito de red, para todos los usuarios si su persistencia es en disco, y de carácter local si su persistencia es en memoria.

Un objeto es un elemento definible dentro de un proyecto que, en tiempo de ejecución, realiza las tareas de un programa. La Rejilla es un objeto.

La variable local es un subobjeto definible dentro de un objeto. Se trata de una variable local al objeto en el que ha sido declarada, y solamente será accesible desde ese objeto o desde otros subobjetos del mismo. La persistencia de este tipo de variables es en memoria.

Un subobjeto es un objeto que está contenido en otro objeto y que no tiene ninguna entidad por sí mismo, ya que depende totalmente del objeto contenedor. El manejador de evento es un subobjeto.

Las variables contienen valores de tipo alfabético, numérico, fecha, hora, tiempo y booleano. Además pueden ser al mismo tiempo arrays unidimensionales.

Ámbito de las variables globales en disco

El contenido de una variable global en disco es común a todos los usuarios y planos de ejecución (tanto en los clientes como en el servidor).

Los planos de ejecución entran en juego cuando desarrollamos en una arquitectura cliente-servidor como la de Velneo V7.

Existen 4 planos de ejecución:
       El 1º plano es el hilo principal de ejecución en el cliente, con el que interactúa el usuario de nuestras aplicaciones.
       El 2º plano también se ejecuta en el cliente, pero a diferencia del 1º plano, la ejecución es asíncrona, es decir, no interrumpe el resto de procesos.
       El 3º y 4º planos se ejecutan en el servidor, el primero de forma síncrona y el segundo asíncrona.

Por tanto, si desde una sesión de Velneo vClient V7 se modifica una variable global en disco, esta modificación afectará tanto a los clientes que estén ejecutando la misma instancia como a los procesos que hagan uso de ella en el servidor (procesos ejecutados en 3º y 4º  plano).

Una instancia es una aplicación abierta en Velneo vServer que está en ejecución. Es posible abrir en un mismo Velneo vServer diferentes instancias de una misma aplicación. Una aplicación Velneo está compuesta por proyectos, tanto de datos como de aplicación, que serán instanciados de forma independiente.

Debemos tener en cuenta que cada vez que se usa una variable global en disco, vClient solicitará al servidor el valor de dicha variable, por si ha cambiado, lo que supone una conexión (socket) a través del enganche correspondiente, lo que puede ralentizar el proceso sobre todo en cloud.

Un socket es una conexión que se establece cada vez que queremos comunicar dos máquinas. La comunicación se ralentiza sobre todo al establecer el socket, ya que una vez establecida el traspaso de información es rápido. En cloud nuestras aplicaciones deben generar el menor número de sockets posible y para ello hemos de optimizar nuestras aplicaciones.

Debemos evitar el uso de variables globales en disco en la definición de propiedades de campos de las tablas. Por ejemplo, un valor inicial basado en una variable global en disco ralentizará el alta del registro. En la Interfaz de nuestras aplicaciones, un campo fórmula con una variable global en disco se recalcula en cada registro de la Rejilla o en comandos de Recorrer lista, lo que en redes lentas se traduce en una mala experiencia de usuario.

Ámbito de las variables globales en memoria

Las variables globales en memoria existen solo en la sesión de la máquina donde se ejecuta la aplicación. Si ejecutamos varios vClients en una misma máquina, las sesiones se ejecutan en diferentes espacios de memoria y por lo tanto no comparten las variables globales en memoria.

En el servidor, la instancia de la aplicación comparte la memoria con todas las sesiones iniciadas por los usuarios, en consecuencia en 3º y 4º plano, cualquier cambio de una variable global en memoria en una sesión afectará al resto de sesiones.

Cada vez que un usuario se conecta al servidor mediante vClient se crea una nueva sesión de usuario también llamado enganche. La sesión es efímera, solo debe dejar un rastro en forma de Log o histórico.

Las variables globales en memoria de un mismo proyecto de datos no se replican entre el cliente y el servidor. Si el vClient  modifica una variable global en memoria, ésta misma variable en 3º y 4º plano no se verá afectada por la modificación de vClient, son espacios de memoria separados.

Los procesos en 1º y 2º plano comparten la memoria en la misma sesión de vClient. Un proceso en 2º plano que modifica una variable global en memoria afectará al resto de procesos en 1º y 2º plano.

Una sesión de vClient solo comparte con otros vClient de la red (local o remota) los siguientes datos:

• Las tablas de la instancia de datos del vServer
• Las tablas en memoria en 3º y 4º plano de la instancia de datos del vServer
• Las variables globales en disco
• Las variables globales en memoria en 3º y 4º plano de la instancia de datos del vServer

Cuando una variable global (en memoria o disco) es modificada en 1º plano, todos los elementos del interfaz activos en ese momento se actualizan inmediatamente. Todas las fórmulas de las propiedades de los objetos se vuelven a calcular. Habrá que tenerlo en cuenta en nuestras aplicaciones para evitar comportamientos no controlados.

Variables del sistema

Aunque la ayuda dice que son variables de tipo local predefinida en el sistema, se puede considerar que su ámbito es global a la aplicación. Están siempre disponibles a través del editor de fórmulas y algunas, como sysUserName, sysCacheClientPath y sysIsAdministrator, se fijan al inicio de la aplicación y su valor estará siempre disponible en cualquier plano de ejecución.

Ámbito de las variables locales

Las variables locales sólo son accesibles desde la instancia del objeto en que se han definido.

Si el objeto es un formulario, las variables locales también son accesibles desde los subobjetos de dicho formulario. Cuando instanciamos el mismo formulario 2 veces, las variables locales de ambas instancias son totalmente independientes.

Los subobjetos de un formulario son los controles, conexiones de evento, manejadores de evento, variables locales, inserciones y extensiones de ficha.

Para insertar un control del proyecto en un formulario usamos un control Vista de datos (o un separador, caja o pila de formularios) que hace de contenedor de dicho control. Las variables locales del control insertado no se comparten con el formulario anfitrión porque el subobjeto es el control Vista de datos y no el objeto incrustado.

Por ejemplo, cuando insertamos una Rejilla en una Vista de datos, las variables locales de la Rejilla no se comparten con las variables locales del formulario.

La tabla no es un subobjeto del formulario y por lo tanto la tabla y el formulario no comparten las variables locales.

Hay una excepción con la compartición de variable locales en el objeto Búsqueda. Si tiene un formulario declarado para introducir las variables locales y éstas coinciden en nombre con las variables locales de la Búsqueda entonces se traspasan automáticamente los valores del formulario a la Búsqueda.

Variables locales especiales

Existen 3 variables locales cuyo identificador está reservado. Se pueden crear manualmente o a través de la opción «Crear variables locales eventos» del menú de Objetos.

• EVENT_SENDER_ID: De tipo alfabética. Contiene el identificador del control que envía la señal. Estará vacía si el que envía la señal es el propio objeto.
  La variable EVENT_SENDER_ID podemos usarla dentro de un manejador para conocer qué Botón ha sido pulsado si existen varios botones que disparan el mismo manejador de evento.
• EVENT_SENDER_COL: De tipo alfabética. Permite obtener información de la columna en la que estamos posicionados cuando se lanza la señal. Estará vacía en todos los eventos salvo los de columna editable de rejilla.
• EVENT_PARAMS: De tipo array alfabética. Contiene información que podrá ser leída desde el manejador de evento que ha ejecutado la señal disparada.

Acceso a variables locales de Vistas de datos

Ya hemos dicho que un objeto del proyecto insertado en un formulario no comparte las variables locales, sin embargo Velneo proporciona comandos que nos van a permitir leer y escribir valores desde el formulario en las Vistas de datos que contenga.

Las Vistas de datos son objetos del proyecto que gestionan Listas de registros de una tabla, la excepción es el formulario que gestiona solo una Ficha. Las Vistas de datos se pueden incrustar en un formulario para mostrar, entre otras cosas, las relaciones maestro-detalle de nuestro proyecto de datos.

Existen 5 controles del formulario que permiten incrustar objetos Vista de datos:

• Vista de datos propiamente dicha que mostrará objetos aparcables (rejilla, multivista, casillero, …) mediante un proceso cargador
• Separador de formularios que mostrará varios formularios en pestañas
• Splitter que mostrará varios formularios con un separador ajustable
• Pila de formularios para crear asistentes mediante formularios sucesivos
• Caja de formularios que mostrará varios formularios en otro tipo de pestañas

Existen 2 comandos de Velneo que nos dan acceso a las variables locales del objeto incrustado en la Vista de datos:

• Interfaz: Set variable local de vista de datos
• Interfaz: Get variable local de vista de datos

Tened en cuenta que estos 2 comandos solo funcionan con objetos incrustados en formularios como Vista de datos. No se puede acceder a variables locales de otro formulario. Por ejemplo, si queremos acceder a las variables locales de un Dock del marco de la Aplicación tendremos que diseñar 2 formularios, uno principal que será el Dock y otro secundario, incrustado como Vista de datos, que contendrá las variables locales que queremos gestionar. El comando que lee el valor de una variable local quedará de la siguiente manera:

Interfaz: Get variable local de vista de datos (.AUTOEXEC.DOCK_CONFIG.CTR_VISTADATOS, VAR_LOCAL, VAR_LOCAL_RETORNO)

Acceso a las variables en Velneo usando el API

En Velneo se ha desarrollado un API que incluye un conjunto de clases que aportan los objetos y funciones para acceder a los elementos de nuestros proyectos. Para programar el API se han incorporado 2 lenguajes, Javascript y QML. En ambos lenguajes podemos usar el conjunto de funciones del estándar EcmaScript-262 (ver http://doc.qt.io/qt-5/qtqml-javascript-functionlist.html).

La interfaz de programación de aplicaciones, abreviada como API (del inglés: Application Programming Interface), es el conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.

Con el API de Velneo podemos acceder a cualquier variable de nuestros proyectos. La herencia permite el acceso y uso de cualquier objeto de la aplicación desde cualquier script.

La herencia es la propiedad que permite que un proyecto pueda hacer uso de los objetos de otro proyecto.

Acceso con el API a las variables globales

Las variables globales son objetos del proyecto de datos. Desde el API usaremos la clase VApp para el acceso a dichas variables.

La clase VApp representa a la aplicación. Siempre estará instanciada en el objeto global theApp.

Las funciones del objeto theApp para el acceso a variables globales son globalVarTo<tipo>() y setGlobalVar(), la primera obtiene el valor de la variable global (tendremos que especificar el tipo de dato que vamos a obtener) y la segunda establece el valor de la variable global.

La variable global se identifica desde el script con el formato «ALIAS_PROYECTO_DATOS/Identificador«

El Identificador es la etiqueta alfanumérica que identifica de forma unívoca al objeto dentro del proyecto y para el mismo tipo de objeto. Este identificador será el que usemos para referenciarlo en las propiedades de otros objetos. El identificador constará de mayúsculas y números exclusivamente.

El objeto theApp representa al proyecto de aplicación principal, es decir, la instancia desde la que iniciamos nuestra aplicación. Por lo tanto, mediante el mecanismo de la herencia tendremos acceso a todos los proyectos de datos de la cadena de herencia. Usar la función mainProjectInfo() de la clase VApp para obtener información del proyecto principal y de todos los objetos de la herencia.

En el siguiente ejemplo obtenemos un JSON con todas las variables globales de la Herencia.

// Obtiene un Array con todas las variables globales en la herencia
// Proyecto principal
var mainProjectInfo = theApp.mainProjectInfo()
// Obtenemos el JSON
alert(JSON.stringify(getAllVarGlobal(mainProjectInfo), null, "  ")

function getAllVarGlobal(ProjectInfo, aLisVarGlobal){
        // Inicializa el array
        aLisVarGlobal = aLisVarGlobal || []
        // Añade al array las variables globales del proyecto
        aLisVarGlobal = getVarGlobal(ProjectInfo, aLisVarGlobal)
        // Proyectos heredados (bucle recursivo en toda la herencia)
        for(var i=0, count=ProjectInfo.legacyProjectCount(); i<count; i++){
                var oProyHeredado = ProjectInfo.legacyProjectInfo(i)
                if (oProyHeredado.type() == 0) {
                        // Solo exploramos los proyectos de Datos
                        getAllVarGlobal(oProyHeredado, aLisVarGlobal)
                }
        }
        return aLisVarGlobal
}

// Devuelve todas las variables globales del proyecto
function getVarGlobal(oProyecto, aVarGlobal){
        var count = oProyecto.objectCount(VObjectInfo.TypeVariable)
        var oObjVarGlobal = null
        for(var i=0; i<count; i++){
                oObjVarGlobal = oProyecto.objectInfo( VObjectInfo.TypeVariable, i )
                aVarGlobal.push ( 
                        {
                                idRef: oObjVarGlobal.idRef(),
                                id: oObjVarGlobal.id(),
                                name: oObjVarGlobal.name(),
                                valor: theApp.globalVarToString(oObjVarGlobal.idRef()).substr(0, 100)
                        }
                )
        }
        return aVarGlobal
}

Acceso con el API a las variables LOCALES

Las variables locales pertenecen a objetos que pueden ser ejecutados desde los proyectos de datos y aplicación. Desde el API usaremos la clase VRoot para acceder al objeto principal que está en ejecución.

La clase VRoot representa al objeto en ejecución. Siempre estará instanciada en el objeto theRoot, accesible desde los scripts del objeto actual.

Las funciones del objeto theRoot para el acceso a las variables locales son VarTo<tipo>() y setVar(), la primera obtiene el valor de la variable local (tendremos que especificar el tipo de dato que vamos a obtener) y la segunda establece el valor de la variable local.

La variable local se identifica con su Identificador único en el objeto al que pertenece.

Para acceder a las variables locales del objeto incrustado en un formulario como una Vista de datos tendremos que obtener el objeto theRoot que representa a dicho objeto incrustado. Existe para ello la función root() que aplicada al objeto Vista de datos nos permitirá acceder a sus variables locales.

Veamos un ejemplo. Obtenemos el ID del registro seleccionado en una Rejilla y lo asignamos a la variable local del formulario incrustado como Vista de datos.

// Formulario principal
var oForm = theRoot.dataView()
// Rejilla con la lista de Fichas
var oGRDLista = oForm.control("GRD_LISTA")
var oLista = new VRegisterList(theRoot)
// Reiniciamos la variable local NID
theRoot.setVar("NID",0)
// Ficha seleccionada en la Rejilla
var nSel = oGRDLista.currentSelect()
if (nSel > -1) {
        // Lista de Fichas de la rejilla
        oGRDLista.getList(oLista)
        // Ficha seleccionada en la Rejilla
        var oFicha = oLista.readAt(nSel)
        // Fijamos la variable local NID
        theRoot.setVar("NID", oFicha.fieldToInt("ID"))
        if (oFicha) {
                // Mostramos la Ficha en el formulario incrustado como Vista de datos
                var oVistaDatos = oForm.control("FRM_INCRUSTADO")
                oVistaDatos.setRegister(oFicha)
                // Establecemos el valor de la variable local de la Vista de datos
                oVistaDatos.root().setVar("NID", oFicha.fieldToInt("ID"))
                // Accedemos al objeto en ejecución de la Vista de datos mediante la función root()
                //         y obtenemos el valor de la variable local de la Vista de datos
                alert(oVistaDatos.root().varToInt("NID"))
        }
}

Existe otra clase VObjectInstance que nos permite instanciar objetos de la aplicación de la misma forma que lo hacemos con el comando de Velneo «Crear manejador de objeto». Para disparar el objeto usaremos la función exec(). Antes de disparar el objeto podemos asignar valores a las variables locales con setVar(). Después de ejecutar exec() y si éste devuelve true, obtenemos el valor de las variables locales con la función VarTo<tipo>().

Variables globales y locales de tipo Array

Las variables array en Velneo no son un objeto independiente del proyecto. Para disponer de un array tendremos que poner a 1 la propiedad Array de una variable global o local.

Los arrays son siempre unidimensionales y el tipo de dato que contiene lo determina el Tipo de la variable. Los elementos del array se acceden mediante la posición que ocupan, siendo 0 la primera posición. En las fórmulas podemos obtener el valor de un elemento concreto del array usando la sintaxis ID_ARRAY[<posición>].

Acceso a variables array globales

Los valores de las posiciones en un array global se pueden leer desde Velneo con la sintaxis ID_ARRAY_GLOBAL[<posición>], pero la asignación de valores solo se puede realizar a través del API. Se podrá trabajar con variables globales de tipo array a través del API de JavaScript mediante las funciones de variables globales de tipo array de la clase VApp.

El uso de un array global facilita la gestión de determinada información al poder agrupar n-variables globales en una sola.

Las funciones del objeto theApp para el acceso a variables array globales son globalVarArrayTo<tipo>() y setGlobalVarArray(), la primera obtiene el valor de una posición de la variable array global (tendremos que especificar el tipo de dato que vamos a obtener) y la segunda establece el valor de una posición de la variable array global. El segundo parámetro de estas funciones es la posición del elemento del array, empezando en 0. Podemos conocer el tamaño de una variable array global mediante la función globalVarArraySize().

Vamos a ver un ejemplo de gestión de variable array global usando el API de Velneo.
Hemos creado en el proyecto de datos una variable global en memoria G_CONEXION de tipo Array. En ella queremos guardar algunos datos de la Sesión actual.
El tamaño del array se irá adaptando al número de elementos creados.

Disponemos de 2 procesos javascript, uno que inicializa los valores del array y otro obtiene un determinado elemento del array.

// Script PRO_CONEXION_INI_JS – Fija los elementos del array global G_CONEXION
// ----------------------------------------------------------------------------
// Usuario conectado
theApp.setGlobalVarArray("MiApp_dat/G_CONEXION", 0, theApp.userName());

// ¿Es administrador?
theApp.setGlobalVarArray("MiApp_dat/G_CONEXION", 1, theApp.isAdministrator()?"Sí":"No");

// Fecha-Hora de la conexión
var f = new Date();
var dias_semana = new Array('domingo','lunes','martes','miércoles','jueves','viernes','sábado');
var fecha = dias_semana[f.getDay()]
+ " " + f.getDate() + "/" + (((f.getMonth()+1)<10?"0":"")) + (f.getMonth() + 1) + "/" + f.getFullYear()
+ " " + ((f.getHours()<10)?"0":"") + f.getHours() + ":" + ((f.getMinutes()<10)?"0":"") + f.getMinutes();
theApp.setGlobalVarArray("MIApp_dat/G_CONEXION",2,fecha);
//theApp.setGlobalVarArray("MiApp_dat/G_CONEXION", 2, f.toLocaleString());

// Código de Pais
theApp.setGlobalVarArray("MiApp_dat/G_CONEXION", 3, theApp.sysCountryIsoCode());

// Nombre de máquina
theApp.setGlobalVarArray("MiApp_dat/G_CONEXION", 4, theApp.sysMachineName());




// Script PRO_CONEXION_GET_JS – Obtiene un elemento del array global G_CONEXION
// --------------------------------------------------------------------------------
// Devuelve el valor del elemento del Array G_CONEXION pasando como parámetro un String CVALOR que describe la información solicitada
var aValores = new Array("USER","ISADMIN","DATELOGIN","COUNTRY","MAQUINA")
var cValor = theRoot.varToString("CVALOR")
var pos = aValores.indexOf(cValor)
// Devuelve en VRETORNO el valor del elemento del Array
theRoot.setVar("VRETORNO",theApp.globalVarArrayToString("MiApp_dat/G_CONEXION", pos))


En el proyecto de Aplicación podremos usar una función que obtenga directamente cualquier valor del array global:

Mensaje(
        "Usuario - " + fun:FUN_G_CONEXION_GET@MiApp_dat.dat("USER") + "\n" +
        "Administrador - " + fun:FUN_G_CONEXION_GET@MiApp_dat.dat("ISADMIN") + "\n" +
        "Conectado el - " + fun:FUN_G_CONEXION_GET@MiApp_dat.dat("DATELOGIN") + "\n" +
        "Código de país - " + fun:FUN_G_CONEXION_GET@MiApp_dat.dat("COUNTRY") + "\n" +
        "Máquina - " + fun:FUN_G_CONEXION_GET@MiApp_dat.dat("MAQUINA"), Informacion)

Acceso a variables array LOCALES

Las variables array locales son el mismo subobjeto variable pero con el valor de la propiedad Array a 1.

Disponemos de un conjunto de comandos Array: que utilizaremos en los procesos para gestionar los valores del array local. Podemos asignar un valor, eliminar uno o todos los elementos del array, obtener el tamaño, ordenar el array e insertar un elemento. Para obtener el valor de un elemento del array no existe un comando, simplemente usamos la sintaxis ID_ARRAY_LOCAL[<posición>].

Existen 2 comandos de Velneo que nos dan acceso a las variables array locales del objeto incrustado en la Vista de datos:

• Interfaz: Set ítem de variable local array de vista de datos
• Interfaz: Get ítem de variable local array de vista de datos

Estos comandos funcionan de la misma forma que con las variables locales, indicando el elemento del array empezando en 0.

Desde el API disponemos también de las funciones del objeto theRoot para el acceso a las variables array locales, las cuales son VarTo<tipo>() y setVar(). La primera obtiene el valor de un elemento de la variable array local (tendremos que especificar el tipo de dato que vamos a obtener) y la segunda establece el valor de un elemento de la variable array local. El segundo parámetro de estas funciones es la posición del elemento del array, empezando en 0.

Hagamos un ejercicio interesante sobre el acceso a variables locales array. A veces queremos pasar parámetros a un formulario y nos encontramos que en Velneo solo es posible hacerlo cuando usamos el comando Crear manejador de objeto. Para los formularios que se muestran en modo Vista, o en los comandos Pedir formulario y Modificar ficha con formulario, tenemos que recurrir a variables globales u otras técnicas con el API, json, … En este caso os propongo una solución creada íntegramente con Velneo nativo, que consiste en guardar los parámetros del formulario en una Vista de datos de un dock de la aplicación y usar los comandos de acceso a las variables array locales del objeto incrustado en la Vista de datos.

• Creamos un formulario FRM_PARAMETROS que solo contenga tantos Arrays como formularios tenga nuestra aplicación que necesiten acceso a parámetros.
• En el evento PRE_INI de FRM_PARAMETROS opcionalmente podemos inicializar los valores de los parámetros. Los valores del array se almacenan como cadenas de texto. Con los números y booleanos la conversión no presenta problemas, con las fechas y tiempos usaremos el formato ISO.

  Rem (Manejador PRE_INI de FRM_PARAMETROS)
  Rem (Aquí podemos documentar los formularios que van a necesitar acceso a parámetros y los inicializamos si es necesario)
  Rem (Parámetros del formulario FRM_CLIENTE)
  Array: Set ( AFRM_CLIENTE, 1, "parámetro 1", LOK)
  Array: Set ( AFRM_CLIENTE, 2, 200.45, LOK)
  Array: Set ( AFRM_CLIENTE, 3, 1, LOK)
  Array: Set ( AFRM_CLIENTE, 4, dateToString(currentDate(), "yyyy-MM-dd"), LOK)
  Array: Set ( AFRM_CLIENTE, 5, dateTimeToString(currentDateTime(), "yyyy-MM-dd hh:mm"), LOK)
  Rem (Parámetros del formulario FRM_PEDIDO)
  Array: Set ( AFRM_PEDIDO, 1, "", LOK)
  

• En un dock de la aplicación insertamos un control Vista de datos CTR_PARAMETROS con el formulario FRM_PARAMETROS. La Vista de datos tendrá la propiedad Visible a 0 porque no necesita interfaz, sin embargo será un contenedor de parámetros que funcionalmente actuará igual que las variables globales en memoria, ya que accederemos a él en toda la aplicación a través del objeto Marco Autoexec.
• Y eso es todo. Ya podemos fijar valores de los parámetros antes de ejecutar un formulario y leer dichos parámetros en el PRE_INI del formulario.

En un proceso determinado ejecutamos lo siguiente:

  Crear nueva ficha en memoria (hNuevaFicha, CLIENTES@apli.dat)
    Rem ( Establecemos los parámetros que deben tenerse en cuenta en el formulario)
    Interfaz: Set ítem de variable local array de vista de datos (.AUTOEXEC.DOCK_APP.CTR_PARAMETROS, AFRM_CLIENTE, 1, "CODIGO_HU33")
    Interfaz: Set ítem de variable local array de vista de datos (.AUTOEXEC.DOCK_APP.CTR_PARAMETROS, AFRM_CLIENTE, 2, 2565.32)
    Pedir formulario (FRM_CLIENTE_EDI@apli.app, LOK)
    If (LOK)
      Alta de ficha (hNuevaFicha)
        Mensaje ("Nueva ficha: " + #NAME)

En el manejador PRE_INI del formulario FRM_CLIENTE_EDI:

  If (! registerExist())
    Rem ( Obtenemos los valores iniciales desde el formulario de FRM_PARAMETROS)
    Interfaz: Get ítem de variable local array de vista de datos (.AUTOEXEC.DOCK_APP.CTR_PARAMETROS, AFRM_CLIENTE, 1, CNOMBRE_INI)
    Interfaz: Get ítem de variable local array de vista de datos (.AUTOEXEC.DOCK_APP.CTR_PARAMETROS, AFRM_CLIENTE, 2, NIMPORTE_INI)
    Modificar campo (NAME, CNOMBRE_INI)
    Modificar campo (IMPORTE, NIMPORTE_INI)

Conclusión

En este artículo hemos hecho un repaso de los aspectos más importantes del objeto variable de Velneo. Para más detalles de los comandos y funciones del API acudir siempre a la documentación de Velneo en el apartado de vDevelop.

La manera más rápida de acceder es buscar en Google la expresión «variable velneo».

Tened muy claros los conceptos de ámbito de las variables y cómo acceder a las variables globales y locales tanto desde otros objetos como desde el API.

Si crees que falta algo importante sobre las variables en Velneo no dudes en comentarlo.