Procedimiento y funciones de usuario

Programación orientada a eventos

La principal característica de FoxPRO es la filosofía de programación orientada a eventos

que propone.

Si te esfuerzas por adoptar esta filosofía, lograras nítidas ventajas respecto a la

programación tradicional, orientada a menús jerárquicos y anidados como ocurre con sus
antecesores (FoxBASE, dBASE, Clipper y otros DBMS)

Esta filosofía esta apoyada básicamente por la programación de teclas (ON KEY LABEL) y
el uso de las cláusulas VALID y WHEN de algunos comandos como GET y BROW
básicamente con funciones de usuario.

Procedimientos y funciones de usuario

Un programa es un conjunto de códigos que realiza una tarea especifica, la cual se puede
llamar con el comando DO <nombre>ya sea desde la ventana de comando o desde otro
programa. Es por eso que a los procedimientos también se les llama subprogramas.

El inconveniente de usar subprogramas es el tiempo que demora FoxPRO en acceder al

disco en busca del código.

Para solucionar este problema FoxPRO permite usar procedimientos, que son
subprogramas ubicados en el mismo archivo que el programa principal, de manera que son
cargados en memoria junto con el programa principal y FoxPRO los lee muy rápidamente
desde memoria.

También es posible usar procedimientos contenidos en otros archivos con el comando DO

<nombre> IN <archivo> lo cual no aporta nada en cuanto a velocidad, por lo que es mucho
mejor usar el concepto de librería que es un archivo PRG donde se ponen todos los
procedimientos que requerimos sean llamados desde cualquiera de nuestros programas de
una aplicación, el cual se carga en memoria con el comando SET PROCEDURE TO
<archivo librería> normalmente ubicado en el programa principal.

Existen dos maneras de transferir información desde y hacia los procedimiento:

1. Usando mismas variables:

Inicializamos una serie de variables y luego tenemos el cuidado de usar exactamente las
mismas en el procedimiento, para que al volver mantengan los valores calculados en el
procedimiento.

PRINCIPAL.PRG
xNUM=2 *****************
xPOT=3 PROC OPERA
RESP=0 *****************
DO OPERA RESP=xNUM^xPOT
? RESP RETURN
RETURN
Nota: Las variables creadas en un procedimiento padre, son publicas para los
procedimientos llamados desde el. Las variables creadas en un procedimiento hijo, NO
existirán al retornar al procedimiento padre.

2. Pasando parámetros:

Pasándole paramentos al procedimiento, para que opere los valores y devuelva el valor, sin
importar las variables que es cada lado se usen.

PRINCIPAL.PRG
xNUM=2 *****************
xPOT=3 PROC OPERA
RESP=0 *****************
DO OPERA WITH xNUM,xPOT,RESP PARA X,Y,Z
? RESP Z=X^Y
RETURN RETURN
FUNCIONES DE USUARIO

Una función se reconoce porque lleva () al final de su nombre y porque retorna un valor que
puede ser numérico, carácter, fecha o lógico.

Su estructura es muy similar a la de los procedimientos solo que se usara FUNCTION en

lugar de PROCEDURE para definirla.

Para ejecutar una función no se usa DO, simplemente se le llama por su nombre con el () al
final.

1. Usando mismas variables:

PRINCIPAL.PRG *****************
xNUM=2 FUNC OPERA
xPOT=3 *****************
? OPERA() RETURN xNUM^xPOT
RETURN
2. Pasando parámetros:

Para transferir parámetros no se usa la cláusula WITH simplemente se introducen dichos

parámetros en el paréntesis.

PRINCIPAL.PRG *****************
xNUM=2 FUNC OPERA
xPOT=3 *****************
? OPERA(xNUM,xPOT) PARA X,Y
RETURN RETURN X^Y
Quizás donde son mas interesantes de usar las funciones de usuario sea en la validación,
osea cláusulas VALID y WHEN de comandos como GET y BROW.

Justamente el uso de esta filosofía es a la que se le da el nombre de programación

orientada a eventos y no a menús jerárquicos o anidaciones, como es habitual en un
principiante de FoxPRO o al que usa FoxBASE, Clipper y otros gestores de bases de datos
del mercado.

Elección entre procedimientos y funciones

Algunas veces nos encontraremos en la duda de crear un procedimiento o una función de

usuario, para realizar una tarea concreta. Existen algunas reglas para determinar el uso de
uno u otro:

Usemos procedimientos cuando sea necesario:

 Dividir un programa en módulos: Ya que es mas fácil mantener el código posteriormente,

debido a la separación de operaciones y el reducido tamaño de los programas, acelerando la
ejecución y se documenta mejor.

 Realizar tareas repetitivas: Los formatos empleados para mostrar datos en pantalla con un
modelo determinado son un ejemplo del uso de procedimientos.

Usemos funciones cuando sea necesario:

 Validar datos o procesos: Dado que las funciones se llaman directamente por su nombre sin
requerir del comando DO.

 Realizar cálculos: Las operaciones en general son mas cómodas de hacer con funciones.

 Sumar procesos: En informes es el único camino para sumar procesos.

En Visual Foxpro, puede declarar rutinas de procedimiento o métodos orientados a objetos

como "PROCEDIMIENTO" o "FUNCIÓN", y no tiene ningún impacto en cómo VFP maneja esa
rutina, como esto:

PROCEDURE miprimerprocedimiento

Messagebox( "ESTO ES UN PROCEDIMIENTO" )

ENDPROC

FUNCTION miprimerfuncion

Messagebox( "ESTO ES UNA FUNCION" )

ENDFUNC
Diferencias entre procedimientos de llamada y funciones de llamada.

Las funciones devuelven un resultado, los procedimientos no

Si una rutina no incluye una declaración RETURN para devolver un resultado, devolverá .T.
(verdadero) por defecto.

El patrón de llamada determina si una rutina es un procedimiento o una función, no su

"definición"

Incluso si su rutina se define como un PROCEDIMIENTO, aún puede llamarlo como una función,
y * es * una función. Si no incluyó una declaración RETURN, la función devolverá .T. (como se
ha mencionado más arriba). (Los métodos orientados a objetos siempre deben llamarse "como
funciones".)

La forma en que llama a una rutina de procedimiento también determina el manejo de los
parámetros.

Aquí están sus dos opciones:

1) Utilice "DO ... WITH" para llamar a una rutina y se considerará un "procedimiento".

Los parámetros se pasarán "por referencia" a menos que estén rodeados por paréntesis, y no
haya manera de "explícitamente" pasar parámetros por referencia ".

(Tenga en cuenta que Set UDFParms NO afecta las rutinas llamadas por "DO ... WITH")

Por ejemplo:

DO MyRoutine WITH ParamByRef, (ParamByValue)

DO MyRoutine WITH @ThisDoesNotWork

2) Omita "DO" y "WITH" y rodee todos los parámetros en un par de paréntesis, y su rutina se
considerará una "función".

Los parámetros se pasarán "por valor" a menos que:

A) Coloca una "@" delante del parámetro, o

B) Coloca paréntesis (adicionales) alrededor del parámetro

Por ejemplo:
SET UDFPARMS TO VALUE

Result = MyRoutine( ParamByVal, @ParamByRef,

(otherParamByVal) )

MyRoutine( ParamByVal, @ParamByRef, (otherParamByVal)

)

SET UDFPARMS TO REFERENCE

Result = MyRoutine( ParamByRef, @OtherParamByRef,

(ParamByVal) )

MyRoutine( ParamByRef, @OtherParamByRef, (ParamByVal)

)