VFP 5.0 como servidor OLE
Por Alberto Rodriguez
© Copyrights 1997 by FoxPress, All rights reserved
FoxPress, Abril 1997
En el desarrollo de software se ha intentado introducir elementos propios de la ingeniería a fin de aprovechar el esfuerzo que supone la contrucción de sistemas informáticos. Una de las áreas en las que más se ha avanzado en este sentido es la que intenta convertir el proceso de construcción de programas en un proceso de conjunción de elementos ya existentes.
En la construcción de un coche se realiza una labor creativa, por ejemplo, el diseño de la carrocería, pero también una labor de ensamblaje de elementos: el motor, las ruedas y los distintos componentes, normalmente ya existentes antes de la creación del nuevo modelo. Lo único que se hace es unir estos elementos.
Este objetivo de crear software a base de combinación de elementos preexistentes se ha plasmado en la gestión de librerías de funciones y más recientemente en el uso de lenguajes de programación orientados a objetos . Estos sistemas intentan aprovechar al máximo los componentes reutilizables de una aplicación para ser utilizados por un gran número aplicaciones similares.
Las librerías de funciones y las librerías de clases están normalmente vinculadas a un lenguaje de desarrollo, es decir, se crean clases dentro de un lenguaje de desarrollo para que sean utilizadas dentro de ese mismo lenguaje de desarrollo.
Desde hace tiempo se está trabajando en romper esta barrera y poder escribir clases en un lenguaje para ser utilizadas por cualquier otro y así aprovechar al máximo los componentes reutilizables de nuestras aplicaciones.
Para poder hacer esto es necesario establecer unos mecanísmos públicos que entiendan tanto las librerías de clases como los lenguajes de desarrollo para intercambiar la información necesaria a fin de interactuar entre sí. Entre los distintos intentos de
establecer un protocolo de comunicación entre objetos de distintos lenguajes, e incluso plataformas, los más importantes son el SOM de IBM, el CORBA de OMG y el COM/DCOM de Microsoft.
De los tres el que tiene una base instalada más grande es sin duda el Component Object Model de Microsoft. Tanto SOM como CORBA son sistemas bien diseñados, pero con poca aceptación en el mercado de aplicaciones de sobremesa. COM/DCOM de Microsoft adolece de algunos defectos, pero es sin duda el líder del mercado, aportando una componente práctica que los otros sistemas no poseen y está apoyado en miles de aplicaciones en el mercado.
Un poco de la historia de COM/ActiveX
El origen de OLE (Object Linking and Embedding) está en el proyecto de un grupo de desarrollo de Microsoft que intentaba establecer un mecanismo para visualizar gráficos de MS-Graph dentro de Power Point. Cuando avanzaron en el desarrollo vieron que lo que estaban haciendo podía ser útil para más proyectos y propusieron crear un protocolo estándar para interconectar aplicaciones Windows. Hicieron una rápida presentación con la aplicación CardFile a Bill Gates, y OLE 1.0 se conviritió en el eje de la conexión entre aplicaciones en Windows.
Partiendo desde el DDE (Dinamic Data Exchange), OLE 1.0 permitía visualizar un documento compuesto por documentos procedentes de distintos orígenes. Así podíamos tener un documento MS-Word que incluyera un gráfico en MS-Graph, una parte de una hoja de cálculo y una imagen de Corel Draw.
OLE 1.0 tenía grandes limitaciones, pero Microsoft no se detuvo ahí, y pensó que este sistema podía ser el eje de toda una estrategia de desarrollo y diseño de software de Windows. Así Bod Atkinson y Tony William con un gran grupo de desarrollo crearon OLE 2.0 y la especificación COM (Component Object Model), es decir el modelo de desarrollo orientado a componentes de Microsoft.
Cuando Microsoft presentó OLE 2.0 y COM a finales de 1993, ya anunciaba que esta sería la base para su estrategia de futuro. En ese momento fueron pocos los que vieron la importancia de este anuncio. Cuando en 1998 aparezca CAIRO, una versión de Windows NT totalmente orientada a objeto, se habrá cerrado un gran ciclo y dispondremos de un sistema operativo basado en OLE 2.0. COM y DCOM (Distributed COM).
OLE 2.0 y los protocolos COM/DCOM en los que está sustentado son una verdadera revolución dentro del entorno de desarrollo en Windows. OLE no es sólo el mecanismo para la edición de documentos compuestos , sino que es una plataforma de desarrollo cooperativo que aprovecha lo mejor de cada componente creando mecanismos bien establecidos para la interactuación entre ellos.
Por ejemplo, cuando Microsoft se dio cuenta de su error sobre el fenómeno Internet, puso a OLE como pieza clave para el desarrollo de sus herramientas y componentes, dándole un nuevo nombre, ActiveX. No es de extrañar esta elección, gracias a OLE/ActiveX Microsoft ha podido, en menos de un año, reorientar toda su estrategia de productos hacia Internet, lo que da muestra de la ventaja de un desarrollo orientado a componentes.
Tipos de ActiveX/OLE
OLE 1.0 sólo disponía de mecanismos para crear documentos compuestos, pero en la actualidad OLE/ActiveX nos permite un abanico mucho mayor de posibilidades, y en un futuro próximo con OLE/DB y OLE/DS este abanico se abrirá mucho más.
Actualmente con OLE 2.0 podemos hacer uso de tres servicios básicos:
Internamente estos servicios utilizan otros protocolos OLE/ActiveX como Uniform Data Transfer o Almacenamiento estructurado, pero estos son los servicios utilizados desde aplicaciones de alto nivel.
ActiveX Document
Es el más antiguo de los servicios OLE y con el que la gente más identifica estos protocolos. Permite insertar un documento, o parte de él, dentro de otro documento, creando lo que se ha venido en llamar un documento compuesto.
Cuando editamos el documento anfitrión también podemos editar los documentos insertados, bien embebidos dentro del documento maestro o bien como documentos independientes, como nos sea más cómodo.
Para facilitar la creación de este tipo de documentos compuestos, Microsoft ideó en un primer momento una opción especial llamada pegado especial, para más adelante incluir la posibilidad de combinar documentos por medio de Arrastrar y Soltar (Drag and Drop) por medio del ratón.
Aun cuando no todos los programas que soportan Documentos OLE utilizan el almacenamiento estructurado de OLE, es posible crear ficheros con estructura nativa de documento OLE.
ActiveX Control
Fueron la evolución de los VBX de Visual Basic, incorporando la tecnología OLE para independizarlos del cliente y pudiendo ser utilizados desde cualquier otra herramienta. Son, habitualmente, controles visuales que extienden las posibilidades nativas de un entorno de desarrollo incluyendo nuevos tipos de botones, visualización de imágenes con un determinado formato, etc...
Aun cuando se asocia la idea de ActiveX Control con controles visuales, estos pueden ser visuales u ocultos. Estos últimos permiten incorporar nuevas funcionalidades dentro de nuestra aplicación, con la importante capacidad de gestionar eventos, a diferencia de otro tipo de librerías.
ActiveX Automation
Es un mecanismo por el cual dos aplicaciones o componentes pueden comunicarse. Viene a sustituir a DDE, teniendo además un interfaz orientado a objeto.
Con ActiveX Automation creamos por medio de órdenes sencillas un objeto del tipo deseado, es decir, una aplicación o componente, y podemos hacer uso de todos los métodos y propiedades que ese objeto nos haga públicos, aprovechando toda la funcionalidad que posea.
Diferencias y similitudes
No es sencillo distinguir en ocasiones cuál de los distintos tipos de OLE/ActiveX estamos utilizando, sobre todo con programas como los que componen Microsoft Office, que normalmente soportan todos los tipos de OLE/ActiveX.
- Soporte parcial
No es necesario que todos los programas soporten todos los tipos de OLE/ActiveX. Casi todos los programas que soportan OLE/ActiveX Document soportan OLE/Automation, pero no todos, por ejemplo, Word Art soporta OLE/ActiveX Document pero no Automation.
- Funcionamiento dependiente o independiente
Los controles OLE/ActiveX son componentes pequeños, normalmente con extensión .OCX o .DLL y no son aplicaciones en sí mismas, mientras que los servidores de OLE/ActiveX Document son habitualmente aplicaciones interactivas, con extensión .EXE.
Existen algunos servidores OLE/ActiveX Document que están programados para ser usados sólo desde aplicaciones, como Word Art o Graph, pero normalmente estos servidores son programas ejecutables de forma independiente.
- Visuales
Aunque la gente asocie OLE/ActiveX a funcionalidades de aspecto visual, OLE/ActiveX Automation es un servicio sin ninguna componente visual, sólo es utilizable desde programas y da una funcionalidad similar a una librería de clases.
Los OLE/ActiveX Control no tienen por que ser visuales, muchos controles OCX no tienen componente visual y son similares al OLE/ActiveX Automation.
- Orientados a la Programación
OLE/ActiveX Control y Automation están más orientados a la programación, mientras que OLE/ActiveX Document está más orientado al uso por herramientas de usuario final (aunque se pueden programar sus contenedores).
- Almacenamiento
OLE/ActiveX Document presenta mecanismos para su almacenamiento, mientras que en OLE/ActiveX Control y Automation no tiene sentido este tipo de tratamiento.
En resumen...
OLE Automation permite al desarrollador de aplicaciones hacer que su aplicación "dialogue" programáticamente de una forma estándar. El programador diseña un entorno y con un controlador de OLE Automation puede invocar rutinas y cambiar propiedades de un Servidor de Automation OLE.
Una aplicación que pueda ser invocada como Servidor OLE multiplica su utilidad. Por ejemplo, Excel que está muy bien dotada de gráficos y fórmulas para calculos financieros, etc., puede ser utilizado por otras aplicaciones para usar esas ventajas que tiene sin que el usuario se entere.
En VFP 3.0, que es un cliente OLE, ya se podía invocar a servidores OLE con rutinas como la siguiente aplicada para Word:
ox =
CREATEOBJECT("word.basic")
ox.ArchivoNuevoPredeter
ox.Insertar("Pepe")
VFP 5.0 como Servidor OLE
A la hora de tratar de servidores OLE, tenemos dos posibilidades:
Controlando VFP 5.0 desde otras aplicaciones
VFP 5.0 ha dado un paso adelante, ya que ha pasado a ser un Servidor OLE, lo que significa que desde cualquier otra aplicación que pueda ser Cliente OLE se pueden crear instancias de VFP con el equivalente a la siguiente orden:
CREATEOBJECT(visualFoxPro.application)
y cambiar propiedades e invocar métodos.
Invocando VFP 5.0 desde un cliente OLE
Desde VFP 3.0
Desde VFP 3.0 podríamos escribir en la ventana de órdenes:
x1 = ;
CreateObject("VisualFoxPro.Application")
?
x1.application.name
que nos devolvería: Visual FoxPro
Desde VB para Aplicaciones
Desde VB para Aplicaciones podríamos crear una instancia de VFP 5.0 con las siguientes órdenes:
Dim oFox as Object
Set o Fox =
CreateObject("VisualFoxPro.Application")
El siguiente ejemplo nos permitiría hacer una consulta en un tabla de Fox y guardar los resultados en un hoja de Excel:
Sub FoxTest()
Dim oFox as
Object
Set o Fox =
CreateObject("VisualFoxPro.Application")
oFox.Docmd("USE
Customer")
oFox.DoCmd("SELECT
contact, phone FROM customer WHERE country = "+ CHR$(39) +
España + CHR$(39) + "INTO CURSOSR cust")
oFox.DataToClip("cust")
Range("A1").Select
ScvtiveSheet.Paste
End Sub
Invocando VFP 5.0 desde un no-cliente OLE
La capacidad de invocar al Servidor OLE de VFP reside en una DLL llamada FPOLE.DLL que viene con VFP 5.0. Si las aplicaciones con las que quiere dialogar no son clientes OLE pero sí pueden cargar DLLs entonces también podrían crear instancias de VFP. Un ejemplo es la posibilidad de llamar a VFP desde un archivo de Help. Para hacer esto deberíamos seguir los siguientes pasos:
Un ejemplo de esto se puede ver en el archivo de ayuda de Visual FoxPro. Desde el menú Visual FoxPro Help escoje Aplicaciones de Ejemplo.
Creando Aplicaciones Servidoras de OLE con VFP 5.0
Con VFP se pueden crear servidores OLE que realicen determinadas operaciones que sean comunes a muchas aplicaciones e invocarla para realizar determinado tipo de operaciones.
1. Crear una Clase OLEPUBLIC
Para crear el servidor lo primero que se necesita es partir de una clase que debe ser definida como OLEPUBLIC.
El siguiente ejemplo que se ha escrito en su totalidad en un archivo se tipo programa (no usando el diseñador de clases) nos crea una clase llamada persona que es definida como OLEPUBLIC.
En esta clase se crean dos propiedades y un método llamado DarNombre que cuando es invocado nos devuelve el valor de las propiedades.
DEFINE CLASS persona AS CUSTOM OLEPUBLIC
Nombre = "Pepe"
Apellidos =
"García"
PROCEDURE DarNombre
RETURN
this.Nombre + " "+ This. Apellidos
ENDPROC
ENDDEFINE
Usando el diseñador de clases deberíamor abrir la información de clases y marcar la opción de OLEPUBLIC.
2. Compilando el Servidor
A la hora de compilarlo, Se puede compilar como .EXE o como DLL. El proceso de compilación realizará dos operaciones:
¿Qué diferencia hay entre crear una DLL o un EXE?
Las diferencias son relativamente pequeñas pero hay que conocerlas. Las DLL suelen ser más rápidas pues se ejecutan en el mismo espacio de procesos que el cliente OLE.
Por su parte los EXE pueden ser abiertos remotamente.
En nuestro caso y para empezar crearemos un .EXE y lo llamaremos: prueba
3. Usando el Servidor tipo .EXE
Una vez compilado y autoregistrado, desde la ventana de órdenes de VFP 3.0 se podría escribir:
ox = CREATE
("prueba.personas")
? ox.nombre
que nos devolvería la palabra Pepe
Un ejemplo más elaborado...
1. Crear un nuevo proyecto.
2. Crear una clase formulario llamda miform basada en form.
3. Cambiar la propiedad ShowWindows a 2.
4. Establecer la clase miform como OLEPUBLIC
5. Escribir en el Init de la clase miform:
Thisform.visible = .T.
6. Crear un fichero llamado INICIO.PRG en el que se puede escribir el siguiente código:
SET ECHO OFF
SET TALK OFF
7. Compilarlo como EXE
8. Desde VFP 3.0 escribir en la ventana de órdenes:
ox = CREATE("proj1.miform")
y ya se ve el resultado. Al haberlo definido con la propiedad ShowWindows = 2 podríamos minimizar VFP 3.0 y veriamos como nos aparece el formulario encima de la pantalla de Windows95.
Para hacer un ejemplo que sea más práctico. Vamos a vincularle una Base de Datos a nuestro ejemplo y vamos a ponerle unos cuantos botones....
9. Volver a abrir la clase y añadir un botón de comandos en cuyo método click se escribe:
SKIP
Thisform.refresh
10. Vincular una Base de Datos al Proyecto: por ejemplo, la que viene en Samples\Data\testdata.dbc
11. Para vincular una tabla a nuestra clase formulario bastará con arrastrar un campo de una de las tablas y soltarla encima del diseñador de clases en la que tendremos nuestro formulario.
12. Como suele haber bastante problema con los path, escribiremos en el Load correspondiente a la clase formulario:
set defa to d:\... <el
que corresponda>
set path to
d:\... <el que corresponda>
use customer (el
nombre de la tabla)
Recompilamos como .EXE nuestro ejemplo y ¡Voilà! Tenemos un magnífica aplicación servidora OLE que puede ser invocada desde VFP 3.0 y veremos como navegamos en una tabla.
Nota: Suele haber bastantes problemas con los path debido a que cuando instancias el servidor, el path se queda en \WIN\SYSTEM32 y debes hacer algo para redirigirlo al lugar donde esta la tabla.
Si en vez de haber creado un .EXE hubieramos creado una .DLL veriamos que no podríamos interactuar con el Servidor de la misma manera que hacemos con el .EXE ya que el ratón nos está indicando actividad. Aunque no se pueda interactuar con el formulario, se le puede tratar como un control ActiveX y darle órdenes desde la ventana del cliente como:
?
ox.application.docmd("skip")
? ox.refresh()
Una vez creada la DLL vemos que junto a la .DLL se nos han creado otros dos ficheros: uno con la extensión .TLB y otro con la extensión .VBR. El TLB es una librería de tipo OLE (Typelibrary) que se puede examinar usando cualquier examinador de librerías OLE como el Examinador de Clases que viene con VFP. El archivo .VBR es un archivo plano con las entradas que se han puesto en el Registry y que es útil si se usa el Setup Wizard a la hora de registrar la libería OLE en otra máquina.
El Registro
En VFP 5.0 los servidores OLE se autoregistran, pero es necesario ejecutar una orden para desregistrarlos.
Para las .DLL será necesario ejecutar: REGSVR32 /u miservidor.dll
Para los .EXE será necesario ejecutar: miservidor.exe /unregserver y seguramente habrá que reiniciar la máquina.
En algún caso tendrás también que reiniciar la máquina para eliminar totalmente una de esas .DLL o .EXE.
Project Info
Si tenemos el proyecto abierto y escojemos desde el menú la opción de información para el proyecto actual veremos que hay tres pestañas y en la tercera pone "Servers". Si pulsamos esa pestaña podremos cambiar la información para cada una de las clases definidas como públicas en nuestro proyecto. Hay que tener en cuenta que esto sólo sucederá si ya hemos compilado una vez el proyecto como DLL y/o EXE y teniendo alguna clase definida como OLEPUBLIC.
La opción Instancing nos permite determinar para nuestros .EXE que si se tiene seleccionada la opción Single Use entonces cada cliente que instancie la aplicación tendrá su propia instancia del servidor. Podremos escribir:
x =
CREATE("proj1.miform")
y =
CREATE("proj1.miform")
con lo que tendremos dos procesos corriendo al mismo tiempo. En este caso habrá que tener en el evento LOAD del formulario la orden:
SET EXCLUSIVE OFF
Si se cambia el Instancing a Multiple Use (lo que quiere decir que se podrá usar múltiples veces), si en una instancia avanzamos un registro y vemos la otra, veremos que también ha avanzado. Para evitar esto se podría poner la propiedad DataSession a 2-PRIVATE.
Si se cambia el Instancing a Not Creatable nos permitirá usar las clases de una aplicación en otra pero de modo específico. Si tenemos alguna definida como OLEPUBLIC especificamos que no queremos que se use.
Bien. Estos son los elementos básicos para usar a VFP como Servidor OLE y para crear aplicaciones Servidoras OLE. En el tintero nos queda la creación de Servidores OLE Remotos y la forma de usar vía Internet y sobre Servidores NT con el IIS esta forma de instanciar Servidores OLE para mostrar páginas Web e información de nuestras Bases de Datos.
Alberto Rodríguez. Es Edior de FoxPress. Se puede entrar en contacto con el en alb@datapress.com
Nota: en la introducción de este artículo se ha usado parte de la exposición de Pablo Almunia en el IIIer Congreso de Desarrolladores en FoxPro