miércoles, febrero 24, 2016

VFP: Seleccionar palabras de un textbox con un solo click

Más de uno habrá tenido la necesidad de poder seleccionar una palabra con un solo click dentro de un textbox:




Aprovechando que alguien hizo la pregunta en un foro de si se podía hacer esto en FoxPro con un solo click, me tomé un momento para aceptar el reto y dar la respuesta.

El siguiente código está en formato texto (guardarlo como "test_selword.sc2") y se puede regenerar el form original con FoxBin2Prg.

*--------------------------------------------------------------------------------------------------------------------------------------------------------
* (ES) AUTOGENERADO - ¡¡ATENCIÓN!! - ¡¡NO PENSADO PARA EJECUTAR!! USAR SOLAMENTE PARA INTEGRAR CAMBIOS Y ALMACENAR CON HERRAMIENTAS SCM!!
* (EN) AUTOGENERATED - ATTENTION!! - NOT INTENDED FOR EXECUTION!! USE ONLY FOR MERGING CHANGES AND STORING WITH SCM TOOLS!!
*--------------------------------------------------------------------------------------------------------------------------------------------------------
*< FOXBIN2PRG: Version="1.19" SourceFile="test_selword.scx" /> (Solo para binarios VFP 9 / Only for VFP 9 binaries)
*
*
DEFINE CLASS dataenvironment AS dataenvironment
     *< CLASSDATA: Baseclass="dataenvironment" Timestamp="" Scale="" Uniqueid="" ClassIcon="1" />

    DataSource = .NULL.
    Height = 0
    Left = 0
    Name = "Dataenvironment"
    Top = 0
    Width = 0

ENDDEFINE

DEFINE CLASS form1 AS form
     *< CLASSDATA: Baseclass="form" Timestamp="" Scale="" Uniqueid="" />

    *-- OBJECTDATA items order determines ZOrder / El orden de los items OBJECTDATA determina el ZOrder
    *< OBJECTDATA: ObjPath="Text1" UniqueID="" Timestamp="" />
    *< OBJECTDATA: ObjPath="Text2" UniqueID="" Timestamp="" />
    *< OBJECTDATA: ObjPath="Label1" UniqueID="" Timestamp="" />

    Caption = "Form1"
    DoCreate = .T.
    Name = "Form1"

    ADD OBJECT 'Label1' AS label WITH ;
        Caption = "Selected word:", ;
        Height = 17, ;
        Left = 32, ;
        Name = "Label1", ;
        Top = 84, ;
        Width = 84
        *< END OBJECT: BaseClass="label" />

    ADD OBJECT 'Text1' AS textbox WITH ;
        Height = 23, ;
        Left = 28, ;
        Name = "Text1", ;
        Top = 28, ;
        Value = This is phrase for selecting words with a click, ;
        Width = 276
        *< END OBJECT: BaseClass="textbox" />

    ADD OBJECT 'Text2' AS textbox WITH ;
        Height = 23, ;
        Left = 28, ;
        Name = "Text2", ;
        Top = 104, ;
        Width = 100
        *< END OBJECT: BaseClass="textbox" />
  
    PROCEDURE Text1.Click
        LOCAL lnLeftLim, lnRightLim, lnWordLen, lnSelStart
        lnSelStart    = THIS.SelStart
       
        *-- Search Left Limit
        lnLeftLim    = 1
        FOR I = lnSelStart + 1 TO lnLeftLim STEP -1
            IF SUBSTR(THIS.Text, I, 1) == ' ' THEN
                lnLeftLim    = I + 1
                EXIT
            ENDIF
        ENDFOR
       
        *-- Search Right Limit
        lnRightLim    = LEN(THIS.Text)
        FOR I = lnSelStart + 1 TO lnRightLim
            IF SUBSTR(THIS.Text, I, 1) == ' ' THEN
                lnRightLim    = I - 1
                EXIT
            ENDIF
        ENDFOR
       
        lnWordLen    = lnRightLim-lnLeftLim+1
       
        *-- If a space was selected, then do nothing
        IF lnWordLen >= 1
            THISFORM.text2.Value = SUBSTR(THIS.text,lnLeftLim,lnWordLen)
            THIS.SelStart = lnLeftLim-1
            THIS.SelLength = lnWordLen
        ENDIF
       
    ENDPROC

ENDDEFINE



Hasta la próxima! :-)

viernes, febrero 12, 2016

Nueva versión v1.19.46 de FoxBin2Prg (arreglos y mejoras) y Extensiones para PlasticSCM v2.5.46


Parte 1: FoxBin2Prg / Parte 2: Extensiones para Plastic

Parte 1: FoxBin2Prg


FoxBin2Prg es un programa pensado para sustituir a SccText/X y TwoFox y mejorar sus funcionalidades, generando versiones de texto estilo-PRG que pueden ser modificadas y permiten recrear el binario original. Puede ser utilizado con herramientas SCM (Administradores de Control de Código Fuente, como VSS, CVS, SVN) y herramientas DVCS (como Git, Mercurial, Plastic, and others), o como programa independiente, para hacer operaciones de Diff (ver diferencias) y Merge (mezclar cambios).


La lista de cambios es la siguiente:

* Bug Fix: Arreglo de bug en método set_UserValue() cuando se intenta obtener información de un error que no puede abrir la tabla (por ej, porque el memo está corrupto)
 

   Cuando ocurre o se detecta algún error se intenta obtener más información de contexto dentro del memo (vcx/scx) para mostrarlo. Si el memo está corrupto se interrumpe la recolección de datos y se queda a medias. Ahora se puede continuar adelante hasta el final, aunque no se pueda leer el memo.

* Mejora: Agregado soporte interno para consulta de información de cfg de directorio, mediante nuevo parámetro opcional, para los métodos API que lo requieren (por ej: get_Ext2FromExt, hasSupport*)
 

   Las funciones API get_Ext2FromExt y hasSupport* permiten indicar en un nuevo parámetro el directorio donde sobre el que se desea obtener dicha información, de modo que pueda evaluarse antes cualquier archivo de configuración que pueda afectar a ese contexto.

* Bug Fix: Cuando se procesa un directorio o un proyecto con todos los archivos, a veces puede ocurrir el error "Alias already in use" (Dave Crozier)
 

   Un problema de garbage collection estaba causando que en determinadas situaciones de error al procesar múltiples archivos una tabla se quede abierta y luego al intentar analizar la siguiente se estaba reabriendo la misma tabla anterior.

* Bug Fix mnx: Cuando se usa '&&' en los textos de las opciones, se corrompe el binario del menú al regenerarlo (Walter Nichols)
 

   Esto pasaba porque se confundían estos símbolos con los comentarios in-line. Se agregó un algoritmo específico para detectar este caso.

* Mejora: El objeto WSscript.Shell da problemas en algunos entornos o bajo ciertas condiciones, por lo que se reemplaza por llamadas Win32 nativas (Aurélien Dellieux)
 

   En algunos equipos WScritp.Shell no mostraba siempre el reporte de errores, por lo que se sustituyó por funcionalidad equivalente basada en funciones API de Windows.

* Bug Fix Frx/Lbx : El ordenamiento de registros de los reportes cambia el orden Z de los objetos próximos que se solapan, pudiendo causar que se visualicen mal (Ryan Harris)
 

   Hasta ahora se venían ordenando los registros internos de los reportes con un orden que estaba provocando problemas para determinados ordenamientos manuales del usuario, haciendo que se pierda el orden correcto de objeto encima/debajo. Se ha quitado dicho ordenamiento para mantener el indicado por el usuario manualmente.

* Bug Frx/Lbx: Cuando se regeneran reportes o etiquetas con textos multilinea alineados al centro o a la derecha, la alineación no es completamente correcta (Ryan Harris)
 

   Esto ocurria porque internamente se estaban guardando los textos con CR+LF en vez de solamente CR, lo que hacía que el parser de VFP interprete la alineación de forma distinta.

* Bug Frx/Lbx: Cuando se agrupan controles en diseño y se convierte a texto, al regenerar se pierden las agrupaciones (Lutz Scheffler)
 

   Esto ocurría porque se estaban ordenando los objetos (ObjType 1,25,26) alfabéticamente en vez de mantener el orden original.

* Bug Fix Pjx: Los archivos SPR y MPR no estan bien representados en la información del proyecto (Ralf Wagner)
 

   Estos archivos no tenían especificado el tipo correcto para ser detectados como archivos de texto. Code Fix aportado por Ralf Wagner.

* Bug Fix Pj2: Se genera un error al regenerar un PJX desde un PJ2 donde algún archivo contiene paréntesis (EddieC)
 

   Se ha corregido la búsqueda de los nombres de archivo para contemplar estos casos.

* Mejora dbf: Nuevo parámetro ExcludeDBFAutoincNextval para evitar diferencias por este dato (edyshor)
 

   Este nuevo parámetro permite que al generar el archivo DB2 con la información de estructura de un DBF con campo autonumérico, no se guarde el dato del siguiente valor a tomar, lo que evita diferencias producidas por el mismo.

* Bug Fix: Cuando se procesa un archivo en el directorio raiz, se genera un error 2062 (Aurélien Dellieux)

   Se ha corregido el algoritmo de recorrido de directorios para contemplar este caso.

* Nuevo: Se a agregado una nueva herramienta fb2p_diff

   Esta nueva herramienta está pensada para quienes solamente quieren hacer una comparación rápida de binarios para ver las diferencias:





Como actualizar el FoxBin2Prg existente:Con descargar el zip y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.



Link de descarga de VFPx


Link de descarga de GitHub



Parte 2: Extensiones para Plastic



Las extensiones para Plastic son un grupo de scripts vbs y programas Visual FoxPro 9 que se configuran dentro de PlasticSCM (herramienta de control de versiones) para poder invocar a FoxBin2Prg desde dentro de la interfaz de Plastic.


La lista de cambios es la siguiente:

> Actualización de FoxBin2Prg: Versión sincronizada con la última versión de FoxBin2Prg



El README.txt explica como se configura en Inglés y Español, y también está explicado en esta nota: Cómo configurar las Herramientas de VFP 9 para Plastic


Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.



Link de descarga de las Extensiones FoxBin2Prg para Plastic de GitHub




Artículos relacionados:

FoxBin2Prg, el sucesor mejorado del Scctext

FoxBin2Prg: Detalle de vistas, Datos de uso, Configuraciones y más

FoxBin2Prg: Guía rápida de uso y configuración


 Saludos!

martes, octubre 20, 2015

SouthwestFox 2015 - Un premio por FoxBin2Prg! :-)

Extracto de la presentación de Southwest Fox 2015 (en inglés), donde me han otorgado el premio VFPx 2015 por mi proyecto Open Source FoxBin2Prg (proyecto: http://vfpx.codeplex.com/releases/view/116407 y también en https://github.com/fdbozzo/foxbin2prg).

 VFPx está alojado en GitHub (https://vfpx.github.io/, anteriormente en CodePlex), y es la continuación de varios proyectos open-source que han sido aprobados por un grupo de Administradores y gurus de Visual FoxPro que han aportado mucho a la Comunidad (artículos, código, sesiones de formación,  libros, etc), que además es el sitio que aloja todos los fuentes de los ejemplos que acompañan al producto en su directorio de instalación y del proyecto Sedna, que es un grupo de proyectos open-source para extender este lenguaje.

Southwest Fox es una conferencia Internacional de desarrolladores Visual FoxPro que se viene realizando desde hace muchos años en Gilbert, Arizona (EEUU), y que cuenta con unos excelentes oradores de la Comunidad FoxPro y de algunas empresas relacionadas.


¡Qué emoción esta noticia! Fue algo realmente inesperado.
Lo dedico a la Comunidad FoxPro, que fue muy importante tanto en las pruebas como en las sugerencias :)







Gracias! :D

domingo, junio 21, 2015

Nueva versión v1.19.45 de FoxBin2Prg (arreglos y mejoras) y Extensiones para PlasticSCM v2.5.45


Parte 1: FoxBin2Prg / Parte 2: Extensiones para Plastic

Parte 1: FoxBin2Prg


FoxBin2Prg es un programa pensado para sustituir a SccText/X y TwoFox y mejorar sus funcionalidades, generando versiones de texto estilo-PRG que pueden ser modificadas y permiten recrear el binario original. Puede ser utilizado con herramientas SCM (Administradores de Control de Código Fuente, como VSS, CVS, SVN) y herramientas DVCS (como Git, Mercurial, Plastic, and others), o como programa independiente, para hacer operaciones de Diff (ver diferencias) y Merge (mezclar cambios).

La lista de cambios es la siguiente:

> Bug Fix Mnx: Cuando se exporta a texto un menu que usa comillas simples o una expresión en el mensaje de las opciones, al regenerar el binario se recortan partes del mensaje de esas opciones (Mike Potjer)

   Por ejemplo, una opción que tenga su texto 'de esta forma' o "de esta" + "forma", no era bien reconocida en las versiones anteriores.

Bug Fix: Cuando se procesan múltiples archivos PJ2, puede ocurrir un error de "variable llError no definida" (Lutz Scheffler)

   Al procesar múltiples archivos, si se cancelaba el proceso a alguno de los archivos no tenía soporte de conversión, se generaba un error de "variable llError no definida"

> Bug Fix pjx/pj2: Los proyectos PJX/PJ2 que referencian archivos de otras unidades de disco causan errores ne esos archivos al procesar con las opciones "*" o "*-" (Matt Slay)

   Esto ocurría porque porque se concatenaba el path del proyecto y el path relativo del archivo, lo que para archivos no-locales generaba un path erróneo, como c:\proyecto\g:\ruta\archivo

> Bug Fix: Cuando se procesan múltiples archivos, a veces los errores no se muestran

   Dependiendo del tipo de error, podía ocurrir que al finalizar un proceso múltiple no fuera reportado ninguno.

> Mejora API-PJX: Nuevo método loadModule() que devuelve el objeto Project interno de FoxBin2Prg cuando se pasa un nombre de proyecto existente

   Al usar la API de FoxBin2Prg (en modo objeto), un nuevo método loadModule() devuelve la referencia interna del objeto del archivo PJX indicado, lo que permite realizar ajustes en sus propiedades antes de la conversión a texto o consultar información del mismo

> Mejora API-PJX: Nuevo método getFilesNotFound() para el objeto Project de FoxBin2Prg, que devuelve la cantidad de archivos del proyecto que no se encuentran y un array con los estados de existencia de cada archivo

  Con la referencia interna del objeto de Proyecto correspondiente al archivo PJX indicado, se puede consultar los archivos no existentes en disco que darían error si se abriera el proyecto con MODIFY PROJECT. El nuevo método getFilesNotFound() devuelve la cantidad de archivos no econtrados en el disco, así como un array con todos los nombres de los archivos del proyecto y sus estados de existencia en disco


Como actualizar el FoxBin2Prg existente:Con descargar el zip y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.



Link de descarga de VFPx


Link de descarga de GitHub



Parte 2: Extensiones para Plastic



Las extensiones para Plastic son un grupo de scripts vbs y programas Visual FoxPro 9 que se configuran dentro de PlasticSCM (herramienta de control de versiones) para poder invocar a FoxBin2Prg desde dentro de la interfaz de Plastic.


La lista de cambios es la siguiente:

> Cambio de codificación de versión: Versión sincronizada con la última versión de FoxBin2Prg

   Desde esta versión, la última parte de la versión va sincronizada en ambos desarrollos vXX.YY.ZZ, para saber a qué versión de FoxBin2Prg corresponden los scripts. Por eso, a la versión v2.5.45 de las Extensiones para Plastic, se corresponde con la versión v1.19.45 de FoxBin2Prg, y de esta forma se puede saber a qué versión de fuentes se corresponde el binario (EXE)
> Bug Fix: Arreglos en los scripts para mostrar algunos errores que no se reportaban


   El mismo arreglo hecho en FoxBin2Prg, implicó hacer algunas adaptaciones en los scripts de Plastic


El README.txt explica como se configura en Inglés y Español, y también está explicado en esta nota: Cómo configurar las Herramientas de VFP 9 para Plastic


Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.



Link de descarga de las Extensiones FoxBin2Prg para Plastic de GitHub




Artículos relacionados:

FoxBin2Prg, el sucesor mejorado del Scctext

FoxBin2Prg: Detalle de vistas, Datos de uso, Configuraciones y más

FoxBin2Prg: Guía rápida de uso y configuración


 Saludos!

domingo, mayo 31, 2015

Nueva versión v2.5.11 de las herramientas Visual FoxPro 9 para PlasticSCM (Incluye FoxBin2Prg.exe v1.19.44)


Estas herramientas son un grupo de scripts vbs y programas Visual FoxPro 9 que se configuran dentro de PlasticSCM (herramienta de control de versiones) para poder invocar a FoxBin2Prg (incluye solo el EXE) desde dentro de la interfaz de Plastic.


Está liberada la versión v2.5.11 de las herramientas Visual FoxPro 9 para PlasticSCM, con los siguientes cambios:

  • Actualizados los scripts para usar la nueva propiedad l_Errors de FoxBin2Prg para conultar errores de sesión.




El README.txt explica como se configura en Inglés y Español, y también está explicado en esta nota: Cómo configurar las Herramientas de VFP 9 para Plastic


Nota: Los fuentes del proyecto FoxBin2Prg y el historial de ambios, están en CodePlex, en este link.


Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.


Link de descarga de GitHub:
https://github.com/fdbozzo/plasticscm-tools-for-visual-foxpro-9


Saludos!

Nueva versión v1.19.44 de FoxBin2Prg (arreglos y mejoras)

FoxBin2Prg es un programa pensado para sustituir a SccText(X) y TwoFox y mejorar sus funcionalidades, generando versiones de texto estilo-PRG que pueden ser modificadas y permiten recrear el binario original. Puede ser utilizado con herramientas SCM (Administradores de Control de Código Fuente, como VSS, CVS, SVN) y herramientas DVCS (como Git, Mercurial, Plastic, and others), o como programa independiente, para hacer operaciones de Diff (ver diferencias) y Merge (mezclar cambios).

Está liberada la versión v1.19.44 de FoxBin2Prg con los siguientes cambios:

> Mejora: Uso de otro método de finalización por error que parece más eficaz entre distintos PCs (Ralf Wagner)

   Cuando se usa FoxBin2Prg.exe desde un programa externo, se retorna un código de error compatible con el ErrorLevel del Sistema. Un usuario reportó que en algunas PCs no se devolvía este código, por lo que se cambió el método de finalización a un método mejor.

> Mejora: Permitir la exportación de datos de DBFs cuando se usa DBF_Conversion_Support:1 y CFG individual opcional.

   Desde esta versión se permite que en el modo de exportación de solo-estructuras DBF (DBF_Conversion_Support:1) se pueda crear archivos de configuración individuales por cada tabla (tabla.dbf.cfg) para permitir que solamente de esas tablas se exporten también los datos. Normalmente solo se quieren las estructuras y justamente lo útil de esta nueva posibilidad, es poder exportar los datos de algunas tablas, como las de configuración o similares, para poder compararlas si cambian sus valores, ya que previamente la única opción era exportar todo o nada.

> Bug Fix: Un arreglo previo en el manejo de errores en cascada provocó un reseteo del último estado de error de proceso, haciendo que a veces los errores no se reporten.

   En la versión anterior se había reportado que cuando se detectaba un error en un archivo al procesar en modo objeto, todos los demás archivos reportaban errores también. Al solucionar esa incidencia y resetear el indicador de errores por ejecución (l_Error), se provocó que cuando hay errores en un archivo, el siguiente archivo sin errores resetee el estado del anterior, haciendo aparecer como si no hubiera errores. En esta versión se agrega un nuevo indicador de errores de sesión que no se reinicia por cada ejecución, y solo lo hace cuando se destruye el objeto o cuando se llama al método ClearProcessedFiles. Nota: Este bug puede haber enmascarado los errores de archivos con problemas al momento de reportar al final.


Como actualizar el FoxBin2Prg existente:Con descargar el zip y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.


Link  de descarga de VFPx:
https://vfpx.codeplex.com/releases/view/116407

Link de descarga de GitHub:
https://github.com/fdbozzo/foxbin2prg


Relacionados:

FoxBin2Prg, el sucesor mejorado del Scctext

FoxBin2Prg: Detalle de vistas, Datos de uso, Configuraciones y más

FoxBin2Prg: Guía rápida de uso y confogiración


 Saludos!

jueves, mayo 14, 2015

Técnicas de programación en VFP: Procesos desatendidos y control de progreso visual

Por: Fernando D. Bozzo

Este es un artículo de una serie que se enfocará en técnicas de programación y optimización en distintas áreas.

Un buen desarrollador asimilará estas técnicas como parte de su forma de trabajo habitual, independientemente de que haga un sistema, ún módulo, una rutina o un programa de pruebas personales, ya que le permitirá programar siempre orientado a la eficiencia, la velocidad de ejecución, la encapsulación, la reutilización y la legibilidad y mantenibilidad del código, o sea, las buenas prácticas.

Al tener en cuenta estas técnicas en cada parte del código y en cada rutina, al final lo que se logra es que el sistema completo esté más optimizado porque sus partes lo están.



   Cuando hablamos de procesos desatendidos, hablamos de procesos que no deben bloquearse esperando la entrada del usuario, son procesos que deben realizar una tarea sin ningún tipo de interacción ni interrupción y que deben controlar tanto la finalización exitosa como la aparición de errores, y en ambos casos no debe haber ningún tipo de mensaje "modal" como un messagbox o form que pida datos de ningún tipo mientras se está ejecutando.

Para esto, es necesario entender la separación de capas (visual, negocio, datos, etc) y el por qué de esa separación (pueden leer un artículo sobre el tema).

Lo primero que a cualquiera no adentrado en el uso de capas (o que las conoce pero es muy cómodo:) se le viene a la cabeza, es hacer un bonito formulario con un botón para procesar, uno para salir y luego, obviamente, un método para hacer el proceso... ¡mal! El proceso conviene que esté aparte, en una librería de clases por ejemplo, o en una librería de procedimientos, pero nunca en el formulario. Este proceso debe hacerse pensando en la reusabilidad, que pueda ser invocado tanto desde un formulario como desde el sistema operativo, si se quiere, o desde otro proceso o programa.



Creando el Proceso Desatendido


Crear un proceso desatendido es realmente simple, pero hay que tener en cuenta algunos pilares fundamentales y respetarlos:

1) Debe estar bien encapsulado: por eso lo ideal es hacerlo basado en una clase de tipo custom o session

2) Debe tener un buen control de errores: esto también es fácil, sobre todo con Try/Catch. Este artículo les explica cómo funciona.

3) No debe contener mensajes de ningún tipo: Ni messagebox, ni wait window, nada, solo el proceso

4) Debe generar una salida de información: Lo habitual es un LOG que luego se pueda consultar o incluso procesar por alguna herramienta para obtener información de estado, pero también debe devolver información de errores, de ocurrir alguno.

5) Opcionalmente puede generar información de avance del proceso

6) Es deseable --aunque no imprescindible-- que también tenga una forma de poder testear el control de errores

7) Opcionalmente puede devolver un código de error DOS para usar con programas externos


¿Parece difícil? Ya van a ver que no lo es para nada.


Primero debemos seleccionar el tipo de clase que vamos a usar: ¿custom o session?

La elección depende de a qué nivel queramos encapsular. La ventaja de la clase session es que está preparada especialmente para usar sesión privada de datos y para ser ligera. La "desventaja" es que no se pueden hacer usando el diseñador de clases, y deben hacerse por código, aunque esto tampoco es un problema.

Por otro lado, la clase custom tiene la ventaja de que se puede hacer usando el diseñador de clases y la desventaja de que es algo más pesada que la session y que no tiene sesión privada de datos, con lo que habrá que tener cuidado al abrir tablas y restaurar áreas de trabajo.

Si el proceso es lo suficientemente complejo como para requerir de más de una clase, una tercer alternativa es hacer una clase session principal que es con la que se interactuará luego, y que esta instancie a las demás clases de tipo custom, con lo que logramos tener una envoltura de sesión de datos privada para todas ellas, aunque entre las clases internas puedan compartir datos.



Veamos un ejemplo práctico simple de un proceso desatendido:

Cálculo que requiere recorrer una tabla y totalizar


Como es un ejemplo, la cantidad de registros no es importante aquí, y el proceso de los datos podrá ser tan complejo como ustedes necesiten, pero a efectos del ejemplo lo vamos a simplificar también.

La tabla la podemos crear con este código desde la ventana de comandos de VFP o con un PRG:

CREATE TABLE T_DATOS ( valor N(10,2) )
FOR I = 1 TO 100
   INSERT INTO T_DATOS (valor) VALUES (I)
ENDFOR
USE


Y la clase la podríamos hacer de esta forma, dentro de lib_proceso.prg, donde intercalaré algunos comentarios para explicar lo que hace y cómo funciona, aunque es muy simple, como puede verse:

*-- lib_Proceso.prg
LPARAMETERS toEx as Exception, tlRelanzarError, tnTotal
#DEFINE CR_LF CHR(13)+CHR(10)
LOCAL loProceso, lnResp
loProceso = CreateObject("c_proceso")
lnResp = loProceso.procesar(@toEx, tlRelanzarError, @tnTotal)
loProceso = NULL
RELEASE loProceso

IF _VFP.StartMode <> 4 OR NOT sys(16) == sys(16,0)
  RETURN lnResp
ENDIF

IF EMPTY(lnResp) && Salida sin error
  QUIT
ENDIF

DECLARE INTEGER OpenProcess IN Win32API INTEGER dwDesiredAccess ;

  , INTEGER bInheritHandle, INTEGER dwProcessID
lnHandle = OpenProcess(1, 1, _VFP.PROCESSID)
DECLARE INTEGER TerminateProcess IN Win32API INTEGER hProcess ;

  , INTEGER uExitCode
=TerminateProcess(lnHandle,1) && Salida con error DOS




La parte anterior es la cabecera del proceso, donde se define la variable del objeto del proceso loProceso y la de respuesta lnResp. En la misma se crea al objeto, que está basado en la clase c_proceso definida bajo este texto, se ejecuta el método Procesar y se guarda el resultado del mismo, que será un código de error, en lnResp.

Con StartMode se determina qué tipo de ejecución estamos haciendo, en este caso solo interesa saber si es desde EXE o APP o si este programa es el principal o no, y por eso se comparan los sys(16) y sys(16,0)

En la última parte de la cabecera, si no hay error simplemente se termina y si hay error (y no es modo desarrollo) se termina con ExitProcess(1), que devuelve ese código como retorno de aplicación, que puede ser interpretado desde otros programas externos o scripts.


La siguiente parte, dentro del mismo prg, define la clase c_proceso, basada en  Session, con 3 métodos: procesar, actualizarAvance y writeLog.

Procesar: Es el método principal, ya que lleva a cabo el proceso que nos interesa que sea desatendido. Genera un log al inicio y fin con algunos datos y normalmente también debería generar algún dato intermedio, que no agrego por mantener el ejemplo corto, usa la tabla con los recursos AGAIN, SHARED y ALIAS que nos permite abrirla más de una vez, tiene un método de testeo de errores sencillo, para comprobar cómo se gestionan, y luego el proceso en sí, que es el SCAN donde se va totalizando en una variable y con un retardo ficticio para que parezca un proceso pesado. Finalmente está la parte de captura del error, obtención de datos extra, generación de Log y recolección de basura, donde se cierra la tabla.


DEFINE CLASS c_proceso AS Session
  cLogFile    = 'log_proceso.txt'
  nTestError  = 0

  PROCEDURE procesar(toEx as Exception, tlRelanzarError, tnTotal)
    LOCAL lnCodError, lcMenErr

    TRY
      WITH THIS as c_Proceso OF lib_proceso.prg
        .writeLog( REPLICATE('-',80) )
        .writeLog( 'Inicio Proceso' )
        STORE 0 TO lnCodError, tnTotal
        USE T_DATOS IN 0 AGAIN SHARED ALIAS _T_DATOS
       
        IF THIS.nTestError = 1
            ERROR 'Error provocado (' + STR(.nTestError,2) + ')'
        ENDIF

        SCAN
           IF MOD(RECNO(),10)=0 THEN
              .actualizarAvance( 'Reg.', RECNO(), RECCOUNT() )
           ENDIF
           *-- El proceso real va aquí.
           tnTotal = tnTotal + valor
           INKEY(0.1,'H') && Simulo retardo proceso c/inkey()
        ENDSCAN

        .writeLog( 'Fin Proceso OK!  Total=' + STR(tnTotal) )
      ENDWITH

    CATCH TO toEx
      lnCodError = toEx.ErrorNo
      toEx.UserValue = 'algun dato importante para agregar'

      TEXT TO lcMenErr TEXTMERGE NOSHOW FLAGS 1 PRETEXT 1+2
         Error <<toEx.ErrorNo>>, <<toEx.Message>>
         Proc.<<toEx.Procedure>>, Line <<toEx.LineNo>>
         LineContents: <<toEx.LineContents>>
         Details: <<toEx.Details>>
         UserValue: <<toEx.UserValue>>
      ENDTEXT

      THIS.writeLog( lcMenErr )

      IF tlRelanzarError
        THROW
      ENDIF

    FINALLY
      USE IN (SELECT('_T_DATOS'))
    ENDTRY

    RETURN lnCodError
  ENDPROC


  PROCEDURE actualizarAvance(tcTexto, tnValor, tnTotal)
  ENDPROC


  PROCEDURE writeLog(tcTexto)
    STRTOFILE( tcTexto + CR_LF, THIS.cLogFile, 1 )
  ENDPROC


ENDDEFINE



actualizarAvance: Es un método vacío, sólo con parámetros, que sirve para ofrecer una posibilidad de monitorizar el proceso desde un programa externo, lo cuál veremos que puede ser muy útil. Observen como la llamada a actualizarAvance() está estratégicamente metida en el código para que no se ejecute por cada registro, sino cada cierta cantidad de registros. Esto es importante para evitar que cualquier monitarización externa afecte al rendimiento del proceso.

writeLog: Es la rutina centralizada para escribir el Log. Para el ejemplo opté por un log básico, sin sistema de buffering y escritura directo al disco, aunque esto en la realidad no debería ser así y es más conveniente agregarle un sistema de buffering, para evitar todas las escrituras intermedias al disco, como ya les comenté en este artículo.


Listo! Ya tenemos nuestro proceso terminado! :D



Primero vamos a probar que funciona desde la ventana de comandos de VFP:

oEx = null
nTot = 0
oo = NEWOBJECT("c_proceso", "lib_proceso.prg")
? oo.procesar(@oEx,,@nTot), oEx, nTot

0 .NULL.     5050


> Como vemos, luego de 5 segundos devuelve código de error 0, que es el retorno del método procesar, devuelve .NULL. para al objeto de errores oEx porque no hubo errores, y devuelve nTot=5050 como resultado de la sumatoria del proceso.


Ahora vamos a testear el manejo de errores:

oEx = null
nTot = 0
oo = NEWOBJECT("c_proceso", "lib_proceso.prg")
oo.nTESTERROR = 1
? oo.procesar(@oEx,,@nTot), oEx, nTot
1098 (object)   0


> En este caso devuelve el código de error 1098 como retorno del método procesar, devuelve (object) como valor de oEx y devuelve nTot = 0 porque no pudo hacer el cálculo (aunque si hubiera fallado en medio del cálculo podría haber devuelto un valor intermedio).

Finalmente comprobamos el mensaje del error devuelto:

? oEx.Message
Error provocado ( 1)


Como pudimos comprobar, el proceso funciona perfectamente y sin mostrar ninguna ventana ni mensaje, tal como debe comportarse un proceso desatendido.

Así como está, este proceso se puede utilizar dentro de un programa, o como proceso independiente en un EXE, o como proceso principal en un web-service, y obviamente también se puede llamar desde un form.

Primero vamos a probar nuestro proceso desde una ventana DOS del sistema operativo, para lo cual antes tenemos que generar un proyecto y un EXE de Fox:

BUILD PROJECT lib_proceso.pjx FROM lib_proceso.prg
BUILD EXE lib_proceso.exe FROM lib_proceso.pjx RECOMPILE



Ahora creamos el archivo test_proc.vbs y le ponemos este contenido:

Dim WSHShell, nExitCode, cEXETool
Set WSHShell = CreateObject( "WScript.Shell" )

cEXETool = Replace(WScript.ScriptFullName, WScript.ScriptName, "lib_proceso.exe")
nExitCode = WSHShell.run(cEXETool & " ""0"" ""0"" ""0"" ""0"" ", 0, True)
MsgBox "CodError = " & nExitCode , 0+4096, "Ejecución 1"

cEXETool = Replace(WScript.ScriptFullName, WScript.ScriptName, "lib_proceso.exe")
nExitCode = WSHShell.run(cEXETool & " ""0"" ""0"" ""0"" ""1"" ", 0, True)
MsgBox "CodError = " & nExitCode , 0+4096, "Ejecución 2"



Aquí estamos probando dos casos de prueba:

  • El primero ejecutará el proceso normal, que puede tardar hasta 10 segundos (esperen, no lo corten! :), y muestra un mensaje con el código de error 0 en un messagebox
  •  El segundo ejecutará el proceso simulando un error, por lo que será instantáneo y mostrará un mensaje con el código de error 1 en un messagebox

Con esto comprobamos que desde otro ejecutable o desde el Sistema Operativo, el proceso devuelve un código de error al estilo ERRORLEVEL de DOS.


Finalmente vamos a probar nuestro proceso desde un formulario de lanzamiento y monitorización, como el de esta imagen, donde pueden ver la situación inicial (el form cargado):



En esta captura está el proceso ejecutándose (va por el 60%) :



Y el fin del proceso con el total al terminar:




El código completo lo adjunto al final del artículo, pero vamos a ver la parte importante en detalle.

El botón que lanza el proceso se llama cmd_Procesar, y en su evento click tiene este código:

Local loEx As Exception, lnTot, lnRet, lcText ;
    , loProceso As c_proceso Of lib_proceso.prg

Try
    This.Enabled = .F.
    Thisform.chk_GenerarError.Enabled = .F.
    loEx = Null
    Store 0 To lnTot, lnRet
    loProceso = Newobject("c_proceso", "lib_proceso.prg")
    loProceso.nTestError = Thisform.chk_GenerarError.Value
    Bindevent( loProceso, 'ActualizarAvance', Thisform, 'ActualizarAvance' )
    lnRet = loProceso.procesar(.F.,.T.,@lnTot)
    lcText = Transform(lnTot)

Catch To loEx
    lcText    = "Error " + Transform(loEx.ErrorNo) + ', ' + loEx.Message

Finally
    Unbindevents( loProceso, 'ActualizarAvance', Thisform, 'ActualizarAvance' )
    Messagebox( lcText )
    This.Enabled = .T.
    Thisform.chk_GenerarError.Enabled = .T.
    Store Null To loProceso, loEx
Endtry



Lo más importante es el Bindevents() que se hace del método actualizarAvance() del proceso, y que se bindea a un método llamado igual en el form, donde está la implementación de la visualización, que solamente tiene este código:


LPARAMETERS tcTexto, tnValor, tnTotal

THISFORM.lbl_progreso.Caption = tcTexto + ' (' + ;

   TRANSFORM(tnValor) + '/' + TRANSFORM(tnTotal) + ')'


Con esto pueden comprobar cómo a un proceso desatendido se le puede acoplar una interfaz para controlarlo. Si quisiéramos comprobar el control de errores, solo debemos marcar el check correspondiente (puesto solo para pruebas) y elegir Procesar:




Y esta es una copia del log generado en log_proceso.txt:

--------------------------------------------------------------------------------
Inicio Proceso
Error 1098, Error provocado ( 1)
Proc.procesar, Line 39
LineContents: ERROR 'Error provocado (' + STR(.nTestError,2) + ')'
Details:
UserValue: algun dato importante para agregar
--------------------------------------------------------------------------------
Inicio Proceso
Fin Proceso OK!  Total=      5050



Pero esto deja abierta otra puerta, y es que podemos cambiar la implementación de la visualización del proceso según cómo lo queramos. Por ejemplo, podemos querer que para ver el avance del proceso se muestre una barra de progreso, que es mucho más visual y útil que un porcentaje, o incluso podemos combinar ambos para tener información más precisa:




Bueno, y con esto acabamos el ejemplo. Hemos conseguido complir todos los objetivos de un servicio desatendido comentados al inicio, tenemos la seguridad del control de errores sencillo pero eficiente, tenemos el log de todo lo ocurrido, podemos lanzar el proceso desde otros ejecutables o scripts y podemos acoplar interfaces para controlarlo.


Una cosa que muchos programadores pasan por alto, sin darse cuenta, es que en un sistema, muchos de los subprocesos que se ejecutan (un cálculo, una actualización) son realmente subprocesos desatendidos, sy solo la interfaz que los llama debería mostrar cualquier mensaje de error, de finalización o con resultados.

Vean vuestros programas y podrán darse cuenta de en muchos casos están mezclando mensajes de estado o messagebox en medio de un proceso. Como ven, hay mucho margen para mejorar eso.


Espero que les haya sido útil :)

Estos son los archivos del ejemplo


Hasta la próxima!