Presentación de Visual FoxPro 5.0

Por Alberto Rodríguez
© Copyrights 1996 by FoxPress, All rights reserved
FoxPress, Octubre 1996

Estoy seguro de que más de uno manifestará su asombro al ver las siglas VFP 5.0 puestas en este artículo, pero es cierto. Si aún no habíamos digerido el VFP 3.0, Microsoft ya nos trae la siguiente versión de este producto que se salta un digito para igualarse con sus hermanos Visual Basic (en la actualidad la versión 5.0 iniciando el proceso Beta) y Visual C++.


Visual FoxPro 5.0 no va a suponer un cambio tan radical para el desarrollador de VFP 3.0 como el que supuso la actualización desde FoxPro 2.6 a Visual FoxPro.

El paso de FoxPro 2.6 para Windows a Visual FoxPro supuso una revolución conceptual en la manera de trabajar: de la programación estructurada a la orientada a objetos y la inclusión generalizada de los eventos en las aplicaciones.

Visual FoxPro 5.0 no supondrá sobre VFP 3.0 ningún gran cambio de concepto en la forma de trabajar. Únicamente la inclusión de nuevas herramientas que uno tendrá que aprender a manejar para sacar todo el partido a sus aplicaciones.

Pero dejemos de divagar y veamos ¡qué aporta VFP 5.0 sobre VFP 3.0!

Menos Recursos

El primer comentario -y me parece que muy importante- es que esta herramienta requiere menos recursos que VFP 3.0 para trabajar. Si miras la documentación de Microsoft puedes ver que VFP 3.0 necesita, según Microsoft, 12 Megas de RAM. Por contra, VFP 5.0, en la documentación de las primeras versiones Beta , se señalaba que sólo necesitaba 8 Megas de RAM aunque a partir de la

Beta 3 y parece ser que será lo que figure en la documentación definitiva se ha establecido que los requerimientos son : "8 Megas de RAM (12 Megas Recomendado)". Esta es la primera buena noticia: requiere menos recursos de RAM y de equipo.


Plataformas

Pero, ¡una cal y otra de arena! Las aplicaciones que se hagan sólo funcionarán sobre plataformas de 32 bits (NT y Win95). Por tanto ya nos podemos despedir del Windows 3.1 y 3.11 aunque esto ya se veía venir desde hace tiempo.

Rapidez

VFP 5.0 no sólo requiere menos recursos sino que también es más rápido. Es verdad, no es una frase del departamento de marketing de Microsoft... El tiempo de carga y de refresco de los objetos y formularios ha mejorado en un 30%. Tal vez en algún próximo número de esta revista se pueda incluir el código que tú mismo podrás aplicar a VFP 3.0 y VFP 5.0 y sacar tus propias conclusiones.

Tamaño

Se me ocurrió sumar el total de K's ocupadas después de la instalación y llegué a 271 Megas. Investigando más en detalle se veía que todo se debía al On-line Documentation Viewer que él solito ocupa 146 Megas. Este On-line documentation vendría a ser el contenido de los manuales -diferente del archivo Help- disponible en tu PC. Este On-line tiene también ficheros .AVI que en un perfecto inglés te explican qué son los objetos, las consultas Off-line, etc.... Supongo que Microsoft cuando traduzca el producto traducirá también estos sonidos a un perfecto castellano.

El Producto

Aunque está pendiente de confirmar, parece ser que sólo habrá versión Profesional. (no habrá ni Estándar ni Enterprise)

Más posibilidades

Ahora tienes 4 formas -sí, cuatro- de hacer aplicaciones con Fox:

- Corriendo tu aplicación dentro de Visual FoxPro.

- Correrla como un ejectuable (.EXE)

- Ejecutarla como un Servidor OLE -sí, has leído bien- desde cualquier Cliente OLE como Excel, Visual Basic o incluso Visual FoxPro 3.0. No sé si te das cuenta que esto implica que Visual FoxPro tiene la capacidad de hacer .DLL.

Vía código te lo podría mostrar de la siguiente manera. Con VFP 3.0 podíamos ejectuar la siguiente orden:

o1 = CREATEOBJETC("word.basic")

que nos crea una instancia de Word, ya que Word es un servidor OLE. Pero ahora, si VFP 5.0 es un servidor OLE se podría ejectuar la siguiente orden desde cualquier cliente OLE:

o1=CREATEOBJET("Visualfoxpro.application")

mira el siguiente código Visual Basic que te puede dar una idea de lo que se puede llegar a hacer. Este código escrito en VBA (Visual Basic for Applications) se podría insertar en un módulo de Excel que nos crearía un objeto aplicación de VFP, abriría una tabla y añadiría los resultados de un query a la hoja de calculo abierta en ese momento:

Sub Foxtest()

Dim oFox As Object

Set oFox = CREATE OBJECT("Visual _ foxpro.application")

oFox.DoCmd("USE clientes")

oFox.DoCmd("SELECT contacto, telefono FROM Clientes INTO CURSOR clien")

oFox.DataToclip("clien")

Range("A1").Select

ActiveSheet.Paste

End Sub

Pero tienes más posibilidades. Por ejemplo, podrías crear una clase en Fox e invocarla desde Visual Basic. Fíjate en el siguiente código:

DEFINE CLASS persona AS CUSTOM OLEPUBLIC

Nombre = SPACE(30)

Apellido = SPACE(45)

PROCEDURE Getname

RETURN This.nombre+ " " + This.apellido

ENDPROC

ENDDEFINE

Desde Visual Basic podrías invocarlo escribiendo:

Set o1 = CREATEOBJECT("foxole.persona")

With o1

.Nombre = "Pepe"

.Apellido = "García"

End With

cName$ = o1.getname()

¿No es increible?

Además, en parte debido al deseo de dar soporte a la Automatización OLE, el modelo de objetos de VFP ha sido dotado de un objeto llamado _VFP de más alto nivel que el objeto _SCREEN que ya existía en VFP 3.0.

Desde un browser de Internet como el Netscape que se puede encontrar en cualquier tipo de máquina (por ejemplo en un 286 con DOS) o en un VAX o lo que quieras usando el FOXISAPI.



Si has tenido que hacer algo en Internet ya habrás oido hablar del ISAPI o conjunto de funciones del API del Internet Information Server (IIS). FoxPro nos trae un subgrupo de este ISAPI que es el FOXISAPI que es otra forma de enganchar aplicaciones Fox al mundo Internet siempre que uses el IIS y el NT.

Más y mejores herramientas

Aunque el producto no trae incorporado el SourceSafe (una herramienta para depurar y mejorar tu código) su integración con el producto como se puede apreciar en la figura siguiente es total.


VFP 5.0 también trae una buena ristra de ActiveX, los controles con los que Microsoft nos está mareando últimamente y que tras complejas y sesudas cavilaciones uno descubre que en realidad no son más que .OCX pero con otro nombre.

El Upsizing Wizard viene ahora dotado con la posibilidad de transformar tu Base de Datos a Oracle.

Un Wizard Application que prepara el entorno de trabajo de tu aplicación, creándote el árbol de directorios, y una serie de clases base. El fichero de este wizard ocupa 5 Megas y es algo que merece ser investigado con más profundidad

El Depurador o Debugger que ¡por fin! ha sido rehecho dotándole de nuevas posibilidades para poder seguir el código con mucha más flexibilidad.

El Editor de los Programas que ha incorporado todas las posibilidades visuales que tiene su hermano de Visual Basic.

El Internet Wizard que te permite hacer consultas sencillas y volcar los resultados en páginas Web.

Automatización Remota o Remote Automation que no es más que permitir que el Servidor OLE esté en una máquina en la red y el Cliente OLE se encuentre en otra máquina diferente. Así tendríamos objetos OLE que navegarían a través de la red. Esta herramienta es bastante útil para crear aplicaciones Cliente/Servidor Three-Tier. Pero, si puede hacerlo en una red local...también podrá hacerlo en otra red llamada Internet...

Ah, se me olvidaba. Nuestro viejo amigo el VFP300.ESL ahora se llama VFP500.DLL. La diferencia de que sea una .DLL en vez de una .ESL es muy importante ya que al ejecutar un .EXE, Windows empieza un nuevo proceso y el ESL era realmente un EXE. Sin embargo, una DLL se puede cargar por otro proceso dentro de su propio espacio de direcciones. La ESL no podía ser una DLL en VFP3.0 debido a que debía de correr bajo Win3.1 (usando win32s). En ese entorno, todas las DLLs comparten las mismas direcciones en las instrucciones. Eso significa que si dos procesos son cargados por la misma DLL, sus datos se podrían cruzar. En los sistema tipo Win32 (NT y Win95) las DLLs tienen sus propias direcciones de memoria, y así los clientes de estas DLLs no tienen que preocuparse por posibles colisiones. Cada cliente puede cargar la DLL dentro de sus propias direcciones de memoria sin temor de colisión con otros procesos. Realmente es mucho mejor.

El Desarrollo en Equipo

Se ha facilitado el desarrollo en equipo ya que varios desarrolladores pueden acceder al mismo proyecto al mismo tiempo. Lo mismo sucede con la Base de Datos que permite acceso multiusuario. Antes para poder añadir o eliminar -en desarrollo- una tabla de una Base de Datos era necesario tener acceso exclusivo.

Asignar Clases a los objetos.

En VFP 3.0 cuando tenías un formulario y una serie de tablas en un Entorno de Datos, podías arrastrar desde el entorno de datos los campos con los que te interesaba trabajar al formulario. Esta forma de trabajo es muy útil y rápida pero tenía una grave carencia y es que nunca podías indicar que la clase sobre la que se basaban esos text fuera una clase que tu habías hecho y no la que viene por defecto en el Fox. Esto ya ha sido solucionado y ahora puedes establecer una relación entre los campos de las tablas y cualquier clase que hayas creado.

Los Ejemplos

Se incluye el conocido Tastrade y el conjunto de ejemplos de controles que ahora se llaman Solutions, pero junto con esto vienen otros ejemplos de Cliente/Servidor, Automatización Remota y un Conjunto de Clases que Microsoft te autoriza expresamente para que las uses en tus aplicaciones.

Si ya has hecho aplicaciones usando clases te habrás dado cuenta de la importancia de tener un buen conjunto de clases y muy bien documentado. Aquí Microsoft te da unas cuantas para que empieces a trabajar a partir de ellas.

Las Carencias

Qué es lo que ha quedado pendiente... Pues una de las cosas más asombrosas que han quedado pendientes ha sido el diseñador de menús que sigue siendo no orientado a objeto. Es algo realmente curioso que esta herramienta esté prácticamente sin cambios desde los días del FoxPro 2.0. En los menús han creado algo que se llama Short Menu Designer que te permite hacer pequeños menús que se muestran al pulsar el botón derecho del ratón o cualquier otro evento similar que quieras usar. Después de hacer el menú y generarlo sólo tienes que añadir en el evento RightClick del formulario la orden

DO MENU1.MPR WITH THIS

Pero sigamos con las carencias y vamos a entrar en la polémica. Visual FoxPro sigue sin poder hacer auténticos ejecutables ya que necesita la librería VFP500.DLL. De todos modos, este es un tema que no debería preocupar demasiado ya que los mismísimos sistemas operativos tienen que acudir a APIs de alto nivel y a complejas funciones y órdenes que hacen del código compilado algo no imprescindible.

Seguro que me podrías mostrar los tests de Sieve y hacerme necesario el código compilado, pero incluso Delphi tiene que llamar a las funciones del API de Windows para poner su entorno en el monitor y muchas funciones de VFP que hacen referencia a manejo de cadenas y acceso a ficheros son comparables y con frecuencia mucho más rápidas que las que proveen los lenguajes compilados.

Ya que hablamos de Delphi te puedo decir que el ejecutable compilado más pequeño que puede conseguir tiene unos 250.000 bytes aunque un tamaño que podríamos decir normal es 500.000 bytes, similar al tamaño de un .EXE de VFP para una aplicación C/S. La diferencia está en que Delphi no necesita runtime. Sin embargo, si necesitas acceder a los datos, especialmente si quieres usar ODBC, entonces ya le puedes añadir 3 Megas del DBE. Y si se te ocurre usar el Reportsmith el tamaño resultante es muy superior al de la DLL que el Fox necesita llevarse consigo.

Por tanto, el que no se pueda hacer un auténtico ejecutable me parece que no es algo tan negativo.

Idiomas

VFP tiene ahora una DLL independiente especialmente dedicada a esto que se llama: vfp4ENU.dll, donde ENU puede también ser DEU, FRA, etc..... Y se tiene la posibilidad de escoger lenguajes para los diálogos internos con el switch "-L".

Un nuevo switch que ha aparecido es el "-A" que te permite cargar el Fox evitando la información del Registry.

Configuración actual

El departamento de soporte de Microsoft también debe estar de enhorabuena porque ahora le será mucho más fácil a ellos y a los desarrolladores conocer qué ordenes SET hay activadas en un momento determinado. Bastará con:

  1. Limpiar la ventana de Comandos haciendo doble clic en la ventana y seleccionando Clear.
  2. Abrir la opción del menú Tools/Options.
  3. Pulsar la tecla de mayúsculas y hacer clic en el botón OK en la ventana de diálogo.
  4. Toda la configuración de tus ordenes SET debería aparecer en la ventana de comandos.

_Screen

Para controlar la pantalla inicial antes de que se muestre en el monitor tenemos ahora la opción de poner en el Config.fpw:

SCREEN = off

o dentro de nuestras aplicaciones también podemos usar _SCREEN.Visible = .F.

Las Vistas Off-line

Las Vistas Offline permiten que las aplicaciones soporten sincronización de datos con lugares remotos. Hay ocasiones en las que se quiere mostrar, recopilar o modificar datos independientemente de la base de Datos del host. Con las nuevas vistas Offline, se pueden usar vistas para conectarse a la Base de Datos de un host (que podría ser cualquier Base de Datos de Fox o un Servidor de datos a través de ODBC) y crear un conjunto de datos para usar off-line. A continuación trabajar off-line ya sea directamente con los datos o a través de una aplicaciónY finalmente, enviar los cambios al servidor.

Algunos escenarios donde las vistas Offline pueden ser interesantes:

1.- Con data warehousing, donde existen grandes Bases de Datos que son mantenidas centralmente en el Servidor MIS. Puedes estar interesado en datos que pertenezcan por ejemplo al departamento de marketing, seleccionar un tipo de datos, llevártelos offline y permitir a todos los miembros del departamento de marketing modificar los datos que te has llevado y posteriormente volcar los datos a la Base de Datos originaria del host.

2.- Si te vas de viaje, antes de salir puedes tomar algunos datos del servidor de la empresa. Luego con tu portátil realizas cambios y a la vuelta vuelcas los datos en el Servidor de la empresa.

Los Formularios

El paso de un formulario en desarrollo a un formulario en ejecución ha sido mejorado y las múltiples pruebas que uno tiene que hacer se solucionan de forma más simple. Puedes llegar a lanzar varios formularios al mismo tiempo cada uno como una tarea diferente.

La ventana de propiedades incluye más información y puedes cambiarle hasta el tipo de fuente y, lo que es más interesante, puedes trabajar en multi-selección con lo que podrías establecer propiedades para varios controles al mismo tiempo.

Los Formularios tienen ahora una opción adicional en la propiedad ColorSource que te permite establecer los colores del formulario sobre el esquema de colores de Windows.

La pestaña de Formularios en la ventana de diálogo Opciones tiene ahora una casilla de verificación llamada Save que guarda los cambios antes de ejecutar el Formulario. Cuando se selecciona, todos los cambios que se hayan hecho en el formulario actual se guardan automáticamente. No serás interrogado con una ventana de diálogo que te pregunte si quieres guardar los cambios en el formulario.


El Grid

El Grid, la bestia negra del desarrollador de VFP 3.0, ha sido dotado con una serie de opciones muy interesantes, como las propiedades siguientes:

.AllowAddNew

.AllowHeaderSizing

.AllowRowSizing

Cuando la propiedad AllowAddNew está como .T., se añade un nuevo registro cuando te encuentres al final de la tabla. Algo parecido a la orden APPEND. Basta con que pulses la flecha hacia abajo y se añade automáticamente un registro al final del Grid.

Las Propiedades AllowHeader/RowSizing te permiten bloquear los procesos de resizing por parte del usuario

Lenguaje SQL

Las versiones anteriores de FoxPro usaban la clausula "Where" para establecer las condiciones de unión. VFP 5.0 usa la orientación marcada por ANSI, usando OUTER JOIN, INNER JOIN, RIGHT, LEFT y FULL JOIN como en el siguiente ejemplo:

SELECT cliente.compañía, facturas.número;

FROM tastrade!clientes INNER JOIN ; tastrade!facturas ;

ON clientes.código_cliente = ; facturas.código_cliente;

WHERE clientes.pasi = "SP"

En este ejemplo estamos juntando dos tablas y seleccionando dos campos. El join ocurre en la cláusula FROM, en lugar de en la cláusula WHERE como se hacía anteriormente. Además de ser consistente con Access, SQL Server y otros que cumplan las normas ANSI, este método es mucho más rápido a la hora de obtener los resultados que sus predecesores. Si vienes de una versión anterior, el Query Designer te cambia automáticamente el código.

Y esto es sólo el aperitivo. Espera lo que viene a continuación.

NOTA: Este artículo se ha escrito sobre una versión Beta y puede que algunas cosas no coincidan exactamente con el producto final.

Alberto Rodríguez es el editor de FoxPress (e-mail: alb@datapress.com)