Etiqueta

30 septiembre 2015

RESTful con Omnis Studio (Parte 2 de 3)

Éste artículo describe cómo configurar un servidor Web Tomcat con interfaz de usuario “Swagger” para su uso con los Servicios Web REST de Omnis, le animamos a descargarse la librería de ejemplo que ilustra lo mostrado aquí, disponible en la web de Aula Omnis.

 

Creando nuestros propios “Web Services”


Un plug-in “Web Server” permite publicar el código de nuestras aplicaciones Omnis, que permitirá a los posibles cliente hacer uso de nuestros “Web Services”. La interfaz para éstos servicios web es vista por los clientes como una API o conjunto de APIs. Omnis genera las API’s RESTful (o ORAs) usando una definición "Swagger", que es el estándar más utilizado con las API’s RESTful.

Podrá ver las Omnis APIs RESTul desde el navegador de Omnis Stido (Studio Browser) como hijos del nodo de su librería bajo el grupo “Web Service Server” (tal cómo ya venia ocurriendo con los servicios basados en WSDL). Cada “ORA” se muestra bajo un nodo separado en el árbol, y varias opciones o acciones con hipervínculos. Podrá ver su definición “Swagger” navegando a trabes de los hipervínculos.

A la hora de crear un servicio Web o una API Omnis RESTful, será necesario ajustar algunas propiedades de la “remote-task” a usar, además de añadirle algunos métodos RESTful. Las clases “remote-task” contiene dos nuevas propiedades que nos permiten configurar un servicio Web de éste tipo, en concreto, la propiedad “$restful” deberá establecerse a “kTrue” para indicar que la “remote-task” es de tipo RESTful, y la propiedad “$restfulapiname” deberá contener el nombre de la API RESTful.

Cuando una “remote task” ha sido definida como RESTful, dispone de un grupo de objetos (localizados bajo el habitual grupo $objs) que son las URI publicadas para los posibles clientes. Una URI contiene uno o más componentes que comienzan por “/”. También podrán incluirse parámetros en la forma “{paramName}” donde cada “paramName” deberá ser único (sensible al uso de mayúsculas y minúsculas) en cada URI. Los URI’s son como clases objeto con sus propias instancias, ya que pueden contener sus propios métodos. Existen algunos métodos especialmente construidos para las URI’s, denominados métodos HTTP. Estos se corresponden directamente con métodos de protocolo HTTP utilizados de forma estándar en todas las API RESTful, y son: “$delete”, “$get”, “$head”, “$options”, “$patch”, “$post” y “$put”.

Los métodos HTTP que conforman una URI contienen algunas características y propiedades especiales, pero todos ellos muestran un parámetro de cabecera denominado “pHeaders”, el cual referencia a la variable “row”, que contiene las cabeceras HTTP recibidas tras la petición RESTful, dicha variable dispone de una columna por cada encabezado HTTP.

En el caso los métodos que aceptan contenidos (“$patch”, “$post” y “$put”) existe un segundo parámetro denominado “pContent”, que referencia al contenido recibido tras la solicitud. Para cada nuevo método HTTP, Omnis creará automáticamente los parámetros “pHeaders” y “pContent”, además de agregar un parámetro de tipo carácter, por cada uno de los incluidos en la URI.

El editor de métodos Omnis contiene algunas características adicionales para su uso con las “remote-task” RESTful. Algunas opciones añadidas al su menú nos permiten insertar nuevos URI, eliminarlos o cambiar sus nombres, además de permitir la inserción de un nuevo método HTTP. También, y cuando el método seleccionado es un método HTTP, el panel de variables mustra dos pestañas adicionales: “RESTful” y “RESTful notes” los cuales nos permiten ajustar los valores de tipo “input”, “output”, así como los códigos de respuesta HTTP y la consignación de notas sobre el método escrito bajo definición “swagger”.

La ventana de diálogo para la configuración del servidor de aplicaciones Omnis (Omnis App Server) contiene dos nuevas propiedades configurables: la “RESTful URL”, que es la dirección URL base, utilizada para invocar al servicio Omnis RESTful, y la “RESTful connection” que controla cómo interacciona el plugin Omnis Web Server RESTful con el propio Omnis.

 

Requerimientos


Para Windows Vista o superior:
  • Omnis Studio dev kit con número de serie valido para el Web Services Plugin.
  • Java Development kit (JDK) o Java SE Runtime environment (JRE) versión 7.
  • Consignar en la variable de entorno de usuario “OMNISJVM” o “OMNISJVM64” la ruta hacia el jvm.dll dentro de su instalación de Java (por ejemplo: c:.\Archivos de programa\java\ jre1.8.0_25\bin\server jvm.dll)

 

Configuración de un servidor web Tomcat para su uso con Servicios Web RESTful

  1. Descargue Tomcat 8.0 o superior, distribución de 32 bits para Windows desde el sitio web http://tomcat.apache.org
  2. Extraiga el archivo zip descargado y muévalo a la carpeta apache-tomcat-8.0.15 adecuada, por ejemplo a: c:\Archivos de programa\apache-tomcat-8.0.15.
  3. Tomcat requiere configurar dos variables de entorno del sistema. Puede optar por configurarlas vía: “System⇒Advanced System Settings” o desde el panel de control de Windows, son las siguientes:
    • CATALINA_HOME necesaria para indicar la ubicación de la carpeta de Tomcat, por ejemplo: c:\Archivos de programa\apache-tomcat-8.0.15.
    • JAVA_HOME necesaria para indicar la ubicación de la instalación del Java JDK o JRE, por ejemplo: c:\Archivos de programa\java\jdk1.8.0_25.
  4. Copie la carpeta “omnisrestservlet” del directorio “clientserver\server” del raiz Omnis Studio sobre la carpeta “webapps” de Tomcat.

 

Instalación de la interfaz de usuario “Swagger”


La interfaz de usuario “Swagger” nos permitirá ver y probar nuestros servicios web Omnis RESTful, desde un navegador web.
  1. Descargue el archivo “swagger-ui-master.zip” desde el sitio web: https://github.com/wordnik/swagger-ui, pulsando el botón “Download ZIP” situado a la derecha de la página web.
  2. Extraiga el contenido del archivo descargado y cópielo sobre la carpeta “dist” del directorio “webapps” de Tomcat, después renómbrelo como “swagger-ui”.

 

Arrancando Tomcat


Una vez completados los pasos anteriores, Tomcat estará listo para iniciarse mediante la ejecución del “startup.bat” ubicado en la carpeta “bin” de Tomcat. Si ya se está ejecutándose, deberá detenerlo primero mediante el “shutdown.bat”, si se esta usando un servidor web alternativo como IIS también se deberá primero detenerlo, para iniciarlo después.

 

Usando Omnis Developer como servidor WS RESTful


Para utilizar el servidor Tomcat que acabamos de instalar como servidor web RESTful será necesario fijar los parámetros “Server port”, “RESTful URL” y “RESTful Connection” desde el diálogo de configuración del servidor, tal y como se muestra a continuación, cambie el 99.99.99.99 por su dirección IP. Para abrir este cuadro de diálogo, despliegue el nodo “Web Service Server” del navegador Omnis Studio (Studio Browser) y haga clic sobre el hipervínculo “Server Configuration”.

 

La librería de ejemplo RESTful Server


Abra el ejemplo RESTful de la librería “swaggerdemo.lbs” (incluida en restfuldemo.zip de Aula Omnis) y observe las entradas “wizard” bajo el nodo “Web Service Server” en el navegador. Este es el valor asignado a la propiedad “restfulapiname” para el “remote task” “rtWizard”. El hipervínculo “Show Method List” muestra los métodos HTTP de la “remote task” de la URI “data”.


Éste ejemplo crea una base de datos SQLite a partir de un archivo de texto separado por comas, que puede ser consultada y actualizada mediante el servicio web RESTful.


Para utilizarlo, abra la ventana “wWizard”, arrastre el archivo de texto “phonelist.txt” suministrado, sobre la ventana abierta y siga los pasos que se indican a continuación, para su acceso a través del servicio web RESTfull.

 

Invocando el servicio RESTful desde “Swagger UI”


Swagger UI (interface de usuario swagger) utiliza un URI para invocar a un servicio web RESTful, al hacer clic sobre el hipervínculo “Web Service Server” podrá ver la URI necesaria, sobre la parte superior del “swagger data”.



Abra el “Swagger UI” sobre un navegador web, mediante introducir la dirección http://99.99.99.99:8080/swagger-ui/index.html, donde 99.99.99.99 es su dirección IP. Introduzca la URI como se muestra arriba y pulse “Explore” para ver el servicio web Omnis RESTful, haga uso del hipervínculo “Show/Hide” para sus métodos.


Pulse “Try it out!” sobre GET, para que el método HTTP “$get” de la URI “/ data” de la “remote-task” “rtWizard” se ejecute, devolviendo la lista de contactos localizados en la base de datos SQLite.

Para insertar un nuevo contacto utilizando PUT, haga clic sobre el “model schema box” y su opción “set as parameter value” para cambiar el valor de los parámetros, después pulse “Try it Out”.



Para ver el registro recién insertado en el servidor junto con el resto de datos existentes, escoja la opción “test” del “”remote-form” 'jsWizard' de la librería “swaggerdemo”.

 

Invocando el servicio RESTful desde Omnis Studio


El objeto “HTTP Web Worker” es el encargado de invocar los servicios web RESTful. La librería de ejemplo “swaggerclient.lbs” incluida, muestra cómo hacer uso de éste objeto para invocar un servicio web RESTful desde una hipotética máquina cliente, en lugar de tener que utilizar la interfaz de usuario Swagger con éste mismo próposito.

Para utilizar la demo en modo cliente, abra la ventana “wRestfulClient”, y escriba la URI “http://99.99.99.99:8080/omnisrestservlet/ws/1234/api/swaggerdemo/wizard/data” donde “99.99.99.99” es la dirección IP de su servidor Tomcat.

 
Seleccione “HTTPGet” y pulse “Test” para recuperar datos del servidor o “HTTPPut” para introducir nuevos valores y enviarlos al servidor para su inserción.

23 septiembre 2015

RESTful con Omnis Studio (Parte 1 de 3)

Para la implementación de servicios web basados en REST, Omnis Studio dispone de un componente externo y un “plugin” encargado de publicar el código Omnis como Servicio Web, ambos son complementados mediante el nuevo componente externo JSON denominado “OJSON”, que permite la adecuada gestión de objetos basados en JSON, profusamente utilizados con REST.

¿Qué es REST? REST es sin lugar a dudas el modelo más extendido hoy en día para usar y publicar servicios web, está considerado como la mejor alternativa al uso de otras tecnologías como SOAP. Un servicio web RESTful es identificado mediante una URI, donde los clientes interactúan con el recurso a través de solicitudes HTTP, obteniendo respuestas mediante un conjunto ya predeterminado de métodos HTTP.

 

Creación de un “Web Service” cliente


Dentro del grupo de objetos externos “Web Worker Objects”, podemos encontrar el “HTTPClientWorker” que es un objeto de tipo “Worker”. Esto significa que funciona de modo similar a como lo hacen los ya conocidos objetos DAM de este mismo tipo, es decir que son ejecutados en segundo plano.

Para utilizar el objeto, deberemos crear una “Object Class” con el “HTTPClientWorker” como subclase. Tal como mostramos en la siguiente imagen:


En la clase-objeto así creada, será necesario definir dos métodos, “$completed” y “$cancelled”, los cuales serán respectivamente invocados tras la obtención del resultado de una solicitud o al producirse su cancelación. A continuación, deberemos crear una variable-instancia de tipo objeto sobre una clase “remote-form” JavaScript, desde donde poder instanciar la clase-objeto anteriormente creada, con la finalidad de poder interactuar con el servicio Web mediante sus métodos. De entre ellos el objeto “HTTPClientWorker” incluye: El “$init()” que lo inicializa de forma que quede listo para realizar las peticiones HTTP que se especifiquen; El “$run()” que ejecuta un hilo en primer plano; El “$start()” que ejecuta un hilo en segundo plano y el “$cancel()” que cancela el subproceso en marcha. El método “$cancel()” es invocado cuando se cancela la solicitud y el “$completed()” cuando se complete la solicitud, la cual retornará una única variable-parámetro de tipo “row” con diversas columnas, el contenido de la respuesta estará incluido en la última columna.

 

Ejemplo de cliente “Web Sercice” basado en REST.


Desde la web de Aula Omnis, podrá descargar una librería dispuesta a modo de ejemplo, sobre el uso de un Servicio Web basado en REST.


Dicha librería permite mostrar información básica sobre la previsión del tiempo, mediante el acceso a un servicio web público proporcionado por WorldWeatherOnline.com. La compañía ofrece dos versiones de su API; una gratuita y otra de pago. El ejemplo se basa en el servicio gratuito, éste puede ser invocado con un límite de 12.000 accesos diarios y 5 veces por segundo, lo cual es más que suficiente para nuestro propósito. Para hacer uso del servicio, deberá obtener antes una clave de la API desde WorldWeatherOnline.com e introducirla al ejecutar la librería por primera vez.

Para probar el servicio y conseguir mostrar el pronóstico del tiempo, abra primero la librería de ejemplo, haga clic derecho sobre el “remote-form” “jsWeather” y seleccione “Test Form” desde el menú contextual. El formulario deberá abrirse en su navegador y mostrar el pronóstico del tiempo para 5 días en Saxmundham. Tenga en cuenta que se ésta utilizando la versión gratuita de la API, la cual tiene un límite de 5 consultas por segundo, por lo que se hace uso de un temporizador para evitar la devolución de un error desde el servidor. Si publica el formulario a un servidor web, el servicio tratará de identificar su ubicación mediante su dirección IP en uso.

Cuando examine el código de la librería de ejemplo, notará que los métodos clave son “GetWeather”, “getData”, “readCurrentData” y “readForecastData” en el caso del “remote-form”  “jsWeather”. “$completed, “$returnVa” en el caso de la clase-objeto “Orest”. A continuación mostramos el método de iniciación “$init()” encargado de inicializar el objeto “Web Services”, configurando los parámetros principales e invocando el servicio web.

; iURI (Char) inicializado como "http://api.worldweatheronline.com"
; iHTTPMethod (Int) iniciado con el valor “kOWEBhttpMethodGet”
; iHeadersList (List)
; iContentChar (Char)
Do iHeadersList.$define(iHeaderName,iHeaderValue)
; call the web service
Do iRestfulObj.$init(iURI,iHTTPMethod,iHeadersList,iContentChar)
Do iRestfulObj.$run() Returns lStatus

A continuación mostramos, el método “$completed” del objeto “Orest”:

; invocado desde el “worker” del cliente con los resultados
Calculate iResponse as pRow
Calculate iResponseHeaders as pRow.responseHeaders
Do OJSON.$formatjson(pRow.responseContent) Returns iReturnStr
Do OJSON.$jsontolistorrow(pRow.responseContent) Returns iJSONRow

Para procesar la salida que nos llega en formato JSON, se hace uso del  nuevo componente externo “OJSON”.

Creando nuestros propios “Web Services”

Un plug-in “Web Server” permite publicar el código de nuestras aplicaciones Omnis, que permitirá a los posibles cliente hacer uso de nuestros “Web Services”. La interfaz para éstos servicios web es vista por los clientes como una API o conjunto de APIs. Omnis genera las API’s RESTful (o ORAs) usando una definición "Swagger", que es el estándar más utilizado con las API’s RESTful.

Podrá ver las Omnis APIs RESTul desde el navegador de Omnis Stido (Studio Browser) como hijos del nodo de su librería bajo el grupo “Web Service Server” (tal cómo ya venia ocurriendo con los servicios basados en WSDL). Cada “ORA” se muestra bajo un nodo separado en el árbol, y varias opciones o acciones con hipervínculos. Podrá ver su definición “Swagger” navegando a trabes de los hipervínculos.

16 septiembre 2015

Configurando un trabajo de impresión (Job Setup)

El diálogo “job setup” o “configuración de impresión” permite al usuario escoger cosas como bandejas de salida, páginas a imprimir, etc. Además de los comandos “Print report” y “Prepare for print” que tradicionalmente permitían mostrar éste diálogo al usuario, podemos hacer uso del comando de notación, con éste único fin.

Toda instancia-informe contiene un nuevo método denominado “$openjobsetup()”, que permite mostrar el diálogo de impresión una vez que creada la instancia-informe. Si se especifica kTrue en el parámetro “$openjobsetup”, el diálogo se abrirá independientemente de cual sea el destino del mismo.

Debemos tener en cuenta que el diálogo sólo se puede abrir una vez creada la instancia-informe y antes de la impresión del primer registro. De modo que deberá usarse durante o inmediatamente después de la ejecución del método “$construct”.

El ejemplo siguiente muestra como hacer uso del método durante la construcción del informe.

Método: “$construct
Parametro         Tipo
pPrompt           Boolean   

Variable local    Tipo
ok                Boolean   

Código del método
If pPrompt
  Do $cinst.$openjobsetup(kTrue) Returns ok
  If not(ok) ;; si el usuario cancela el trabajo se cierra la instancia
    Do $cinst.$close()
    Quit method
  End If
End If

Guardado de la selección


Todo lo establecido en el diálogo de configuración de impresión quedará automáticamente guardado junto con el informe. Sin embargo, debemos tener en cuenta que tal información no es multiplataforma, por lo que sólo será válida si se está imprimiendo en la misma plataforma.

09 septiembre 2015

Introducción a la abstracción y la herencia

Éste artículo está especialmente dirigido a los desarrolladores que tras una larga experiencia programando con Omnis 7, han decidido dar el salto a la programación con Omnis Studio. Mostramos una pequeña introducción sobre cómo utilizar las posibilidades de la herencia que aporta Omnis Studio, atendiendo a lo que en programación orientada a objeto (OO) significa la “abstracción”. La abstracción y la herencia (en Omnis Studio) se entiende como la creación de elementos genéricos, con la intención de ser usados muchas veces en nuestra aplicación, consiguiendo que su tiempo de programación sea menor a la vez que más consistente, más sencilla y más fácil de mantener.

Imaginemos que disponemos de una ventana donde mostrar el domicilio y otros datos de un registro de direcciones, seguramente también deseemos disponer de algunos botones en ella, que permitan al usuario buscar, editar, insertar y eliminar registros. Sin embargo éste tipo de funciones a menudo serán también necesarias en muchas otras ventanas, tales como contactos, proveedores, etc. Por supuesto podríamos optar por programar de nuevo todas estas funciones para cada ventana, pero naturalmente no es eso lo que pretendemos.

Aquí es donde la abstracción y la herencia entran en juego. La idea es crear una clase-ventana principal con los botones estándar de manejo de datos, mientras que los campos en sí, estarían dibujados sobre otras ventanas secundarias y los datos a manejar sobre una única variable de tipo “row”, como por ejemplo "ivDataRow", la cual sería una variable del ámbito instancia, definida sobre la clase-ventana principal. Note que ésta variable “row” no se llama algo así como "ivDireccionesRow", sino que tiene un nombre genérico, pues la idea es que pueda ser usada con todas las tablas de datos y no sólo con la de direcciones, además (en este momento del diseño de nuestra aplicación), se supone que aún no sabemos qué tablas vamos a manejar, por lo tanto, deberemos disponer de una segunda variable de instancia de tipo “Item Reference”, a la que llamaremos “ivTableRef”, la cual apuntará a la hipotética tabla en uso.

Usaremos la variable “Item Reference”, en el método “$construct()” de la ventana, posteriormente éste método será abstraído (Overwrite) en cada sub-ventana, para sustituir la asignación de la clase-tabla a su correspondiente. Su código sería el siguiente:

Do ivDataRow.$definefromsqlclass(ivTableRef)

Ahora heredaríamos la clase-ventana principal, junto con el método anterior, a continuación mostramos una imagen de una posible ventana para la edición de datos, naturalmente tendremos que añadir los botones de buscar, editar, y así por el estilo, en la super-clase, junto con la programación que cada uno necesite.

 
A modo de ejemplo, mostramos lo que podría ser el código para el botón “Borrar”:

On evClick
  No/Yes message (Icon,Sound bell) {¿Desea realmente eliminar el
   registro "[IvDataRow.[ivColsToBeDisplayed.c1]]"?}
  If flag true
    If ivDataRow.$delete()
      Do ivDataRow.$clear() 
      Do $cinst.$redraw()
    Else
      OK message Database message (Sound bell) {El registro no 
      ha podido    eliminarse.//Error: [ivDataRow.$getErrorText()]}
    End If
  End If

Puesto que no sabemos cual es el nombre de la columna que queremos mostrar en el mensaje genérico, usamos la forma corta “c1” para mostrar la primera columna de “ivDataRow”. Atendiendo a nuestra filosofía de trabajo, deberemos programar todos los métodos específicos de cada tabla de datos en su propia clase-tabla. Para crear una sub-clase, podemos hacer clic sobre la clase-principal en el navegador (Studio Browser) y seleccionar la opción del menú contextual “Make Subclass”, tal y como mostramos a continuación:


Ahora vamos a ver cómo crear una ventana para la edición de registros, especificando la tabla a usar. Por ejemplo, creamos la clase ventana “wAddress”, que a su vez hereda los elementos de la ventana principal. A continuación abstraemos (Overwrite) el método “$construct()” haciendo clic sobre él con él botón derecho del ratón y seleccionando la opción “Overwrite”, ha continuación configuramos la variable de instancia “ivTableRef” mediante el comando “Set Reference” y finalmente (no olvidar) activamos la ejecución del código en la ventana principal mediante el comando “Do inherited”. Por ejemplo:

Set reference ivTableRef to $tables.T_Address
Do inherited

Ahora sólo tendríamos que añadir los campos a la ventana, asignándole sus respectivos “$dataname” referenciados des la variable “ivDataRow”, tal y como se muestra en el ejemplo siguiente:


De éste modo podemos crear nuestras ventanas en sólo unos pocos pasos y poner en práctica el uso de ventanas heredadas. Las funciones generales pueden ser escritas de forma genérica en la super-clase y en el futuro agregar otras nuevas que serán automáticamente heredadas o puestas a disposición de todas las sub-clases.

02 septiembre 2015

Uso de “String Tables” para la localización de aplicaciones en diferentes idiomas

Para poder seguir las explicaciones que se ofrecen en éste articulo, deberá descargar las librerías de ejemplo, disponibles en Aula Omnis. Encontrará dos ficheros que podrán ser usados a partir de la versión de Omnis Studio 2.1, para Windows descargue el fichero “Strngtab.zip” y para MacOS el “Strngtab.sit.hqx”, descomprimirlos sobre una misma carpeta, en ella deberá encontrar las siguientes librerías:

STRTEST.LBS
  • Esta librería muestra cómo hacer uso de las “String Tables” para añadir soporte multi-idioma a nuestras aplicaciones. Al hacer clic sobre el botón “language”, se nos permitirá seleccionar uno de entre lista desplegable, después bastará con pulsar el botón “Set Language” para que todos los controles se redibujen, mostrando el idioma seleccionado. El ejemplo muestra el uso de las principales características de la interfaz “String Table” y su función “$getText()”.

TABLE.LBS
  • Esta librería muestra cómo configurar los controles “String Label” para muestren la información obtenida de entre varias “String Table”.

A continuación mostramos las funciones implicadas en el uso de “String Tables”, atendiendo a su creación, almacenado, eliminación y uso.

 

Funciones para la creación de “String Tables”:


$loadtablefromlist(≤Nombre de Tabla≥,≤Ruta≥,≤List≥)
Crea una “String Table” a partir de una variable de tipo “List”. Como cabe suponer, la tabla es creada en memoria. Para guardarla se deberá usar la función “$savestringtable”.

$loadcolumn(≤Nombre de columna≥,≤Nombre de Tabla≥,≤Ruta≥) 
Crea una “String Table” usando una sola, de las columnas de la tabla.

$loadstringtable(≤Nombre de Tabla≥,≤Ruta≥) 
Carga completa de la “String Table” indicada.

 

Funciones para guardar “String Tables”:


$savestringtable(≤Nombre de Tabla≥) 
Guarda una “String Table” de entre las anteriormente creadas.
Nota: No se especifica ruta, puesto que éste parámetro solo es necesario durante su creación.

 

Funciones para la eliminación “String Tables”:


$removestringtable(≤Ruta≥) 
Elimina del disco una “String Table”.

$unloadstringtable(≤Nombre de Tabla≥) 
Descarga de la memoria una “String Table”.

$unloadall() 
Descarga de la memoria todas las “String Tables”.

Nota: Ambas funciones son opcionales, ya que todas las “String Tables” se descargan automáticamente al salir de Omnis.

 

Funciones para el acceso y uso de “String Tables”:


$setcolumn(≤Nombre de Columna≥) 
Establece la columna actual a la indicada ≤Nombre de Columna≥. Se puede indicar tanto un nombre, como un número.

Nota: Es sensible al uso de mayúsculas y minúsculas. Si se están utilizando varias “String Tables”, deberá usarse la forma ≤Nombre de Tabla≥.≤Nombre de Columna≥, por ejemplo, “StringTable.$setcolumn(“Table1.French”)” o bien “StringTable.$setcolumn(“Table1.3”)

$getcolumnname([≤Nombre de Tabla≥] ) 
Obtiene el nombre de la columna actual. No es necesario especificar ≤Nombre de Tabla≥ si se está trabajando con una sola “String Table”.

$getcolumnnumber([≤Nombre de Tabla≥] ) 
Trabaja del mismo modo que la función anterior, pero devuelve el número de la columna en lugar de su nombre.

$redraw(≤Hwnd≥) 
Esta función puede utilizarse para volver a dibujar una ventana completa. En la librería de ejemplo “STRTEST”, se usa la función “StringTable.$redrawAll()” para volver a dibujar todas las ventanas tras la selección un nuevo idioma. Seguramente es el mejor modo de refrescar los controles de tipo “String Label” de nuestras aplicaciones.

$colcnt([≤Nombre de Tabla≥]) 
Devuelve el número de columnas de .

 
$rowcnt([≤Nombre de Tabla≥]) 
Devuelve el número de filas en .

 
$loadlistfromtable(≤Nombre de Tabla≥) 
Copia una “String Table” sobre una variable de tipo “List”.