miércoles, febrero 26, 2014

Nueva versión v2.4.7 de las herramientas FoxPro para PlasticSCM

Por: Fernando D. Bozzo

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

- Actualizada la versión de FoxBin2Prg a la v1.19.13

Estas herramientas son un grupo de scripts vbs y programas Visual FoxPro 9 que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg (incluye solo el EXE) desde dentro de la interfaz de Plastic.
El README.txt explica como se configura en Inglés y Español.


Link de descarga:
https://github.com/fdbozzo/foxpro_plastic_diff_merge


Saludos!

Nueva versión v1.19.13 de FoxBin2Prg (arreglos, mejoras)

Por: Fernando D. Bozzo

Está liberada la versión v.1.19.13 de FoxBin2Prg con los siguientes cambios:

  • Arreglo de bug: Si se cambia la configuración de NoTimestamp en foxbin2prg.cfg se toma el seteo opuesto (Reportado por Ryan Harris) 
  • Encapsulado del archivo de configuración foxbin2prg.cfg para poder testearlo con FoxUnit
  • Cambio interno de l_UseTimestamps por l_NoTimestamps
  • El seteo ExtraBackupLevels del archivo de configuración foxbin2prg.cfg ahora permite desactivar los backups si se le pone 0 (propuesto por Ryan Harris)
  • Quitada la verificación de la existencia del archivo foxbin2prg.log, solo se puede usar el archivo de configuración con Debug=1 para activar el log (de paso se evita un acceso a disco innecesario)
  • En el header de los TX2 mostrar el archivo sin ruta, ya que generarlo de sitios distintos genera diferencias innecesarias (propuesto por Ryan Harris)
  • Creados un montón de casos de prueba de FoxUnit para verificar todas las configuraciones de foxbin2prg.cfg


A qué afecta:
- Si se usa el archivo de configuración por defecto, no afecta a nada. Pero si se ha cambiado la configuración de NoTimestamps, entonces se estará usando el valor opuesto al elegido, que afecta a versiones texto y binarios (no es para preocuparse, tiene que ver con vaciar o no el campo Timestamp)


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


 Saludos!

lunes, febrero 24, 2014

Nueva versión v2.4.5 de las herramientas FoxPro para PlasticSCM

Por: Fernando D. Bozzo

Hoy es día de publicaciones :-)

Está liberada la versión v2.4.5 de las herramientas Visual FoxPro 9 para PlasticSCM.

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

El README.txt explica como se configura en Inglés y Español.


Link de descarga:
https://github.com/fdbozzo/foxpro_plastic_diff_merge


PD: Aunque el link es de GitHub, mi repositorio local es de Plastic y uso la sincronización que tiene para actualizar el repositorio de GitHub ;-)


Saludos!

domingo, febrero 23, 2014

FoxBin2Prg: Control de código fuente con PlasticSCM

[Actualizaciones]
01/03/2014 - Agregado apartado sobre las herramientas de productividad incluidas (scripts .vbs)
26/02/2014 - Agregada aclaración sobre el merge del minuto 00:29:48 del video
--------------------------

Por: Fernando D. Bozzo

En esta nota voy a comentar cómo sería el trabajo con control de código fuente y FoxBin2Prg. Aunque el ejemplo es con PlasticSCM, la operativa general en el desarrollo se aplica a cualquier SCM.


Primero una breve mención a SourceSafe


Para quienes lo sigan usando, les recomiendo pasarse cuanto antes a cualquier otra herramienta SCM. El motivo principal es que Microsoft ya no soporta este producto, cuya última versión es de 2005 (Visual SourceSafe 2005, versión que muchos desconocen) y una gran mayoría de los que lo usan siguen con la que salió en Visual Studio 6, que es del año 1998 más o menos!
Tiene, además un gran problema de escalabilidad y para mantener el histórico de los archivos, cosa que en un SCM es algo crucial. Simplemente es demasiado fácil borrar archivos del historial sin querer o por problemas internos, y no son recuperables.
Si a pesar de la advertencia no les queda otra que seguir usándolo, sepan que FoxBin2Prg se integra bién con el mismo gracias al archivo de configuración foxbin2prg.cfg y la reasignación de extensiones, de hecho, permite usarlo para hacer el merge de los binarios como nunca lo habíamos visto ;-)


Ahora sí, a lo que nos ocupa


En esta ocasión voy a comentar sobre el trabajo con PlasticSCM, una herramienta SCM de pago, pero que permite su uso gratuito a cualquier persona o grupo de hasta 15 miembros y que se use para controlar el código de cualquier tipo de aplicación comercial o de uso interno. Solo es necesario registrarse con un email válido, descargarse la última versión (sacan una cada 2 semanas o menos) y generar y descargarse el archivo de licencia de 15 usuarios que debe renovarse cada 6 meses de forma gratuita.

El programa es multiplataforma (Windows, Mac, Linux [con WINE]) e incluye el componente cliente y servidor, pudiendo instalarse ambos o uno solo, ya que por defecto utiliza Microsoft SQLCE 3.5 en Windows (hasta 4 GB por base de datos) y SQLLite en Linux. El backend es configurable, soportando SQLServer, MySQL, Postgress y otras bases de datos, lo que permite instalar el componente cliente en un PC y el componente servidor en un servidor dedicado, aunque también se pueden instalar ambos componentes en la misma PC de desarrollo (yo lo uso así).

La configuración usada ha sido la de usuario/password manejada desde el gestor de usuarios incluido, pero permite varios esquemas de autenticación, incluyendo LDAP, Directorio Activo y otros.

La configuración interna que usé para trabajar es esta:




Estas son las herramientas en Visual FoxPro preparadas para trabajar con PlasticSCM (todo lo necesario, incluyendo el ejecutable v1.19.12 de FoxBin2Prg):
https://github.com/fdbozzo/foxpro_plastic_diff_merge (el README.txt explica como configurarlas, tanto en Español como en Inglés)

FoxBin2Prg puede ser usado con la interfaz SCCAPI 1.0 (la que usa SourceSafe) o solo, pero recomiendo usarlo solo, o sea, no usar la integración de Visual FoxPro con SCCAPI, ya que limita mucho lo que se puede hacer, y sobre todo la forma de trabajar.
SCCAPI estaba pensada (o configurada) para bloquear los archivos cuando se desprotegen, lo que impide que otros desarrolladores puedan trabajar con el mismo archivo. Esto en un entorno de desarrollo local o distribuido no es escalable, ya que se depende de que quien tenga el archivo bloqueado lo libere cuando pueda o quiera, y un desarrollo no puede depender de eso.

Trabajar sin la integración FoxPro/SCCAPI tiene muchas ventajas, aunque para quienes venían trabajando de esa forma (yo incluido:) les pueda resultar algo no natural al principio, ya que implica un cambio de mentalidad, pero que con la práctica se puede comprobar que es mejor, y como ventaja adicional, los proyectos abren mucho más rápido, como ha sido siempre para los proyectos que no están bajo control de código integrado con SCCAPI.

Video del ejemplo usado en este post:



Esquema de trabajo en FoxPro con un SCM


La que voy a describir es la forma de trabajar que encontré más cómoda, pero no es la única, y se basa en el trabajo en rama por tarea, un concepto en el que ya hablaban los de Coding Horror allá por 2007. Esto quiere decir que para cada tarea se hace una rama, se trabaja en ella, y cuando se finaliza la tarea y las pruebas unitarias, se integra en la rama principal o en la de testing integrado.



En nuestro ejemplo hay dos desarrolladores, Dev_1 y Dev_2. Se comienza partiendo desde la rama principal o Trunk (/main en el ejemplo), que contiene la última versión estable del proyecto, en este caso la v1.0, se la que se crea una rama de testing integrado, llamada "TESTS" en este caso, y cada desarrollador se crea una rama particular de trabajo desde la v1.0

Si hubiera más desarrolladores, la mecánica sería la misma, cada uno se crea su propia rama partiendo de la última Release estable.

Luego se hace el desarrollo, cada uno por su lado, con la seguridad de que ninguno interferirá con el otro, en el sentido de bloquear al otro, como pasa en SourceSafe.

El video muestra como cada desarrollador tiene que hacer una serie de modificaciones en los mismos componentes (el peor caso), siendo estos un form, una librería de clases, un reporte, un report label y un menú.

Dev_1 tiene que agregar un campo de Costo en la página DATOS de un pageframe de un form:



Dev_2 tiene que agregar una nueva página CALCULOS al mismo pageframe del mismo form:



Este form usa la clase form_bus de una libreria de clases de negocio llamada test.vcx
La librería tiene un método existente, pero cada desarrollador necesita agregarle un método. Dev_1 necesita agregarle el método set_Costo_Articulo() y Dev_2 el método set_PrecioArticulo(). Cada uno hace sus pruebas por separado, y finalmente integran sus cambios en la rama TESTS para poder hacer pruebas integradas entre Dev_1 y Dev_2 antes de que suba todo a la rama principal.

Para hacer el check-in del código se deben generar las vistas de texto con FoxBin2Prg.


[Actualizado - 26/02/2014 >>]
Respecto del merge manual, cuando toca hacerlo, en la vista de Merge se muestran tanto las versiones texto como los binarios. Como en esta operación lo que "manda" son las versiones texto, ya que son las que se mezclan visualmente, hace que los binarios se deban pasar "como están" a la vista de cambios pendientes, y por eso se puede ver como en el minuto 00:29:48, una vez terminado el merge de los tx2 se seleccionan los binarios que quedan y se elige "Merge keeping workspace changes" o "Mezclar manteniendo los cambios del workspace". Esto los deja en el panel de "Pending Changes" o "Cambios Pendientes", donde se regeneran desde las versiones tx2 recién mezcladas para mantenerlos sincronizados. [<<]

Se debe tener cuidado de que las librerías, forms, etc, no estén abiertas en alguna sesión de FoxPro, porque si no será imposible para FoxBin2Prg abrir el archivo para realizar su trabajo, y mostrará un error, además de generar un .ERR para el archivo en cuestión. Por ello, recordar hacer CLEAR ALL/ CLOSE ALL antes de las conversiones.

Regenerar los binarios de esta manera tiene otra ventaja: Para quienes tengan librerías de clases o forms de varios años y con muchas modificaciones o que han pasado por muchas manos, les habrá pasado de que a veces se pueden comportar de forma extraña o dar errores, o el clásico "agrego un código en un método pero se sigue ejecutando el método viejo!", que es una de las formas más raras de corrupción de una clase o form. En estos casos, el paso a texto y posterior regeneración del binario soluciona algunos problems, y en todo caso, por lo menos se puede ver e código en claro y reparar como un PRG!

Con esta forma de trabajo además no es necesario que se pongan como ReadOnly los archivos a modificar. Solo se hace el check out de binarios y versiones texto a modificar, se hacen las modificaciones, se generan las versiones texto (las llamo TX2), se regeneran los binarios, se hacen algunas pruebas para comprobar que ha ido todo bien y se procede al check in final (binarios y texto). Lo de mantener ambos archivos es por seguridad y por performance. Por seguridad, porque donde se trabaja realmente en diseño es sobre el binario y siempre es bueno tenerlo por si acaso, ya que FoxBin2Prg sigue siendo beta hasta que tenga el suficiente tiempo en uso como para considerarlo versión final, y por performance es porque si el proyecto tiene muchos archivos y solo se guardaran las versiones texto, al hacer el ejecutable final en un servidor de integración (o a mano), habría que sumar el tiempo de regeneración de todos los binarios, lo que podría demorar un rato.

En este punto de comprobar si está todo bien, puede que se quiera hacer un ejecutable para comprobarlo, y obviamente esto provoca que se recompilen todos los binarios y que figuren como modificados ante el control de código fuente. No pasa nada, se pueden comprometer los ficheros cambiados o solo comprometer los que se les haya hecho el check-out previo y deshacer los cambios del resto.

Lo que realmente importa es que para la versión definitiva sí se debe recompilar todo, ya que FoxBin2Prg intenta hacerlo de la mejor forma, pero si se invoca la regeneración de binarios desde el explorador de archivos, FoxBin2Prg no puede saber cuál es el proyecto al que corresponde cada archivo, por lo que lo recompila desde su ubicación, y como consecuencia puede que los archivos #include o referencias a componentes a rutas relativas no se encuentren, dando errores de compilación. Por eso es que siempre se debe realizar una compilación de todo el proyecto en la fase final o de pruebas, así estos problemas desaparecen

Lo de recompilar los binarios al regenerar se hace porque si no hay propiedades o métodos que de otra forma no se ven en tiempo de diseño, aunque realmente estén ahí. Es una cosa extraña, pero sé que pasa y así es como se soluciona, aunque esa compilación provoque los errores comentados.

Si por alguna causa no ha salido todo bien y ha ocurrido algo con el binario, se puede recuperar desde los .BAK que se generan para cada extensión o desde la propia herramienta SCM. La cantidad de .BAK que se hacen por defecto es 1, pero se pueden hacer más si se requiere, indicándolo en el archivo de configuración foxbin2prg.cfg


Vámonos por las Ramas, pero no matemos al Integrador!


La rama TESTS podría no ser única y solo simboliza una rama previa a la principal donde un grupo de desarrolladores que están trabajando en un proyecto determinado hará su integración de código. Podría llamarse "integración_proyecto_X" o de cualquier otra forma, pudiendo haber una rama por cada proyecto independiente.

En el caso de múltiples proyectos que deban integrarse, se puede crear una rama de integración adicional, previa a la "TESTS" de nuestro ejemplo, de modo de repartir el trabajo de integración equitativamente entre los desarrolladores y el integrador principal (debería haber uno) que además es el encargado de verificar el código y los requisitos no funcionales.
Si hay mucha integración, este reparto de trabajo de integración es necesario para "no matar al Integrador", ya que la responsabilidad es muy grande y también lo es la posibilidad de cometer errores, y el Integrador también es humano :-)

Cualquiera que haya realizado esa tarea sabe de lo que hablo.


¿Pero entonces cada desarrollador sube lo que quiere?


No, cada uno trabaja en lo que tenga asignado. El proyecto en el que están trabajando puede haber comenzado hace meses, por ejemplo en la v0.1, pero cuando finalizan conviene que hagan su entrega de código integrándola en una rama de Integración que se crea basada en la última versión estable de Producción, ya que nadie mejor que los desarrolladores para saber qué código debe estar presente sí o sí. De esa forma cargan con una parte de la integración que corresponde a las versiones intermedias que hayan pasado y pueden comprobar que sus cambios funcionan bien antes de pedir la integración definitiva, y es en este "pedir" donde entra en acción el Integrador principal, que gracias a que le entregan el código integrado en la última rama estable los únicos cambios que verá son los realizados por ese proyecto y no tendrá que lidiar con las diferencias entre las distintas versiones, ya que esa parte fue resuelta antes, y eso le permite hacer su trabajo mejor y más rápido y no debe soportar la carga de todo.


Tenemos una librería que se modifica demasiado!


Siempre puede pasar que haya una o varias librerías que tengan un tamaño apreciable y muchos, muchísimos métodos y clases que se están cambiando todo el tiempo y que incluso con FoxBin2Prg muestran muchos cambios y es difícil de integrar: ¿Qué hacer en este caso?  Cuando ocurre eso es porque no se ha previsto su crecimiento o porque se le han hecho modificaciones por muchas manos que no se han animado a hacer lo que se debió hacer desde un principio: Refactorizar

La única solución posible que dará mayor seguridad a futuro y bajará los costes de mantenimiento que cada vez son mayores con cada nuevo cambio es refactorizar como parte del trabajo diario y no sólo cuando las cosas van mal, porque en ese momento ya es tarde y hasta podría ser imposible o demasiado costoso acometer esta tarea postergada miles de veces.


Algunos consejos


Aunque en los requisitos no funcionales se suele incluir la encapsulación y la nomenclatura de variables y objetos, lo cuál no siempre se respeta, en la integración de código esto juega un papel fundamental, ya que cuanto más se respeten estas recomendaciones más fácil será la integración.

Un ejemplo: si en un form se dejan todos los objetos con su nombre por defecto y el form usa pageframes o uno con varias páginas, cuando al momento de integrar toque hacer un merge eso será lo que se vea: pageframe1.container1.textbox1, pageframe1.container1.textbox2, etc. ¿Cómo puede el integrador hacer bien su trabajo si ni siquiera sabe para qué son esos controles cuyo nombre no indican nada respecto de su función u objetivo?

Otro: Dentro de varios "textbox1" que hay en un form, resulta que se requiere en tiempo de merge cambiar uno de sitio o de nombre, debiendo porque resulta que ambos desarrolladores han tenido que agregar uno o más controles y los dejaron con sus nombres por defecto, de modo que el integrador se encuentra con dos objetos con el mismo nombre. ¿Cuál es el bueno? Y si hay que renombrar uno, ¿cómo identificar sus métodos y no confundirlos con el otro?



Una razón más: La nomenclatura correcta permite que las diferencias sen mucho menos, y esto implica dedicar menos tiempo y tener mayor seguridad sobre lo que se está integrando.


Creo que queda claro el problema, y tanto en el video como en la captura anterior se puede ver que uno de los motivos por los que no tuve mayor problema en hacerlos rápido, incluso mezclando los mismos métodos o controles, es gracias a usar una nomenclatura correcta donde cada objeto y variable tiene su nombre con un significado de para qué sirve.


Trabajo yo solo, ¿tiene sentido usar Control de Código?


¡Por supuesto! No solo porque de paso se tiene un backup, sino porque se pueden aprovechar las herramientas relacionadas al SCM, como la herramienta de Diff y Merge. La de Merge no será mayor problema porque al trabajar solo nunca habría conflictos para resolver y todos los merge serán automáticos, pero a la de Diff es a la que mayor provecho se le sacaría, ya que permite ver las diferencias entre las distintas versiones de un programa y eso permite encontrar los errores o las modificaciones realizadas mucho más rápido. Además de todo esto está la historia: Todo lo que se guarda en control de código fuente tiene historia, con lo cuál se puede identificar si una modificación o un error es de hace un mes o de hace 10 años.


[Actualizado - 01/03/2014 >>]

Herramientas de productividad incluidas (scripts .vbs)


Conversando con distintos desarrolladores veo que no todos leen el Readme.txt y la cabecera de los scripts .vbs incluidos.

Las herramientas de FoxPro para trabajar con PlasticSCM son un conjunto de programas FoxPro 9 y scripts .vbs que están preparados para configurarse en el GUI de Plastic

Respecto de FoxBin2Prg en particular, en el artículo "FoxBin2Prg: Detalle de vistas, datos de uso, configuraciones y más", en la última parte de Palabras Finales se describe como agregar los scripts incluidos en el menú "Enviar A" para poder usarlos desde el menú contextual del explorador de archivos. [<<]


Notas finales



Seguramente me esté dejando algunas cosas fuera porque el tema es extenso, pero si fuera así no descarten que lo agregaré aquí mismo para que quede lo más completo posible.

Cualquier duda o pregunta, por favor no se corten y pregunten, ya sea en el blog, en el foro Google de FoxPro o por correo, que esto se trata de probar, equivocarse y aprender.


Hasta la próxima!


Relacionados:
Instalación de PlasticSCM paso a paso
FoxBin2Prg: Detalle de Vistas, datos de uso, configuraciones y más

Nueva versión v1.19.12 de FoxBin2Prg (Mejoras para SC2/VC2)

Por: Fernando D. Bozzo

Está liberada la versión v.1.19.12 de FoxBin2Prg con los siguientes cambios:

  • Generación de VC2/SC2 con nuevo header metadata <OBJECTDATA>. Esta es una mejora propuesta por Ryan Harris para centralizar el UniqueId, el Timestamp y el ZOrder y reducir bastante las diferencias en un diff/merge. Un ejemplo: Si se tiene un form con 100 controles y se agrega o quita uno intermedio, antes se podía ver como el ZOrder de cada control cambiaba (se renumeraba), generando en el peor de los casos hasta 100 diferencias (en este ejemplo), una por cada ZOrder en cada control, y ahora se generarían hasta 2 diferencias!, una en el nuevo bloque centralizado en la definición de la clase y una en el control agregado o quitado.
  • Mejora estética en presentación en cabecera VC2/SC2. Es un detalle visual, pero permite ver mejor y más claro la información de la cabecera de las clases y forms
  • Arreglo de casos de prueba FoxUnit para contemplar la nueva funcionalidad
  • Limpieza, refactorización y optimización de código


A qué afecta:
- A la generación de versiones texto, pero es compatible con los anteriores ya generados. Si se está usando para Diff/Merge, conviene regenerar los SC2 y VC2 que tengan componentes visuales.


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


 Saludos!

jueves, febrero 13, 2014

Nueva versión v1.19.11 de FoxBin2Prg (Optimizaciones / Correcciones)

Por: Fernando D. Bozzo

Está liberada la versión v.1.19.11 de FoxBin2Prg con los siguientes cambios:

  • Optimizaciones WITH/ENDWITH con una ganancia de velocidad de conversión de hasta un 16% más rápido.
  • Arreglo bug: Solo se contemplaba un nivel de #IF, dando un error si se enidaban más niveles. Me toco un ejemplo de código donde se tiene la norma de anidar bloques de código con #IF/#ENDIF (práctica que no recomiendo, por cierto) y que fallaba por tener varios de estos #IF anidados
  • Arreglo bug: Al regenerar el PJX no siempre se establece el directorio por defecto correctamente. En ocasiones esto puede provocar que al abrir el  proyecto luego de regenerado pregunte si se quiere prefijar el directorio actual como predeterminado. No es importante, pero si molesto.
  • Agregado test unitario de FoxUnit para comprobar el arreglo del #IF anidado


A qué afecta:
- A la generación de binarios y versiones texto


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


 Saludos!

lunes, febrero 10, 2014

Ejemplo de Merge en Visual FoxPro 9 con FoxBin2Prg en PlasticSCM

Por: Fernando D. Bozzo

Preparé un pequeño veideo de muestra en YouTube sobre un merge de un form.
No pretende mostrar una forma de trabajar, sino solo un merge que suele ser lo más complejo (y en Fox, que yo sepa, imposible hasta ahora)

Al próximo le pongo el sonido :-)  Bueno, finalmente pude ponerle algo de música, gracias a Google :-)

http://youtu.be/rxeIe5gQEdM


Para ver un ejemplo mucho mejor y más completo, leer esto:
FoxBin2Prg: Control de código fuente con PlasticSCM


Saludos!




domingo, febrero 09, 2014

Nueva versión v1.19.10 de FoxBin2Prg (ClearUniqueID, config.Tipo Conversión)

Por: Fernando D. Bozzo

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

  • Agregada parametrización para el soporte de conversión permitido por cada tipo de archivo (0=Ninguno, 1=Solo TX2, 2=TX2 y Binarios) en foxbin2prg.cfg. Esto permite habilitar o deshabilitar ciertos tipos de conversión. Por ejemplo, si se quisiera habilitar la generación de DBFs, además de permitir la de DB2 (versión texto), se debe poner DBF_Conversion_Support = 2 (por defecto ahora es 1 para evitar la pérdida accidental de datos). Sirve para lo mismo que NoTimestamps, para minimizar las diferencias entre archivos al comparar.
  • Arreglo de seteo NoTimestamps por defecto
  • EXPERIMENTAL: Nuevo parámetro de configuración "ClearUniqueID" en foxbin2prg.cfg para borrar el UniqueID de los binarios y versiones texto. Funciona bien y aparentemente FoxPro no hace uso del UniqueID, pero requiere más pruebas. Para usarlo se debe poner ClearUniqueID = 1 en el foxbin2prg.cfg
  • Ajuste de algunos casos de prueba FoxUnit



Nota: En el archivo foxbin2prg.cfg están documentados los parámetros permitidos.


A qué afecta:
A la generación de binarios y de versiones texto.


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

Saludos!

sábado, febrero 08, 2014

Nueva versión de FoxBin2Prg v1.19.9 (configuración, parametrización, info depuración)

Por: Fernando D. Bozzo

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


  • Nuevos items de configuración en foxbin2prg.cfg (ver info en el mismo)
  • Bug en Localización: Al recompilar con el archivo de localización foxbin2prg_en.h renombrado a foxbin2prg.h daba errores de sintaxis
  • Mejorada la información de depuración de los archivos LOG cuando está habilitado (Debug=1)
  • Nueva parametrización de la cantidad de backups, ahora por defecto en un solo .BAK (antes era de 10)
  • Habilitado el archivo de configuración foxbin2prg.cfg por defecto
  • Cambio funcional por defecto: Ahora los timestamps están desactivados por defecto. Esto se puede cambiar en el archivo foxbin2prg.cfg


A qué afecta:
A la generación de binarios y de versiones texto.


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

Saludos!

martes, febrero 04, 2014

Nueva versión v1.19.8 de FoxBin2Prg (bug PageFrame / Scripts vbs)


Por: Fernando D. Bozzo

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

- Arreglo bug PageFrame: Daba un error de ActivePage cuando se intentaba ejecutar un scx/vcx regenerado que usa PageFrame

- Nuevo test unitario para comprobar la solución del bug

- Parámero cNoTimestamps='1' agregado a scripts de conversión batch


A qué afecta:
Solo a la generación de binarios. Las versiones texto son válidas.


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

Saludos!

domingo, febrero 02, 2014

Nueva versión v1.19.7 de FoxBin2Prg (OLE, Timestamps)

Por: Fernando D. Bozzo

Acabo de liberar la versión v1.19.7 de mantenimiento, con los siguientes cambios:

- Encapsulados los campos OLE en un solo sitio (antes estaban en 2, cabecera y objeto)

- Ajustado el Blocksize de los binarios generados: Esto hace que el tamaño de los mismos sea algo menor, más coincidente con los binarios originales

- Nuevo parámetro cNoTimestamps: Indicando '1' en el nuevo parámetro, se generan todos los timestamps vacíos. Útil para minimizar diferencias en operaciones de Diff y Merge


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


Les agradezco el feedback por correo y en los comentarios.

Saludos!

FoxBin2Prg: Detalle de Vistas, datos de uso, configuraciones y más

[2018/09/12 - Agregadas algunas enumeraciones de valores para menúes] 
[2015/05/10 - Actualizado con todas las mejoras hasta FoxBin2Prg v1.19.43] 
Nota: Si ya leíste el artículo, podés leer solo los cambios buscando la fecha de modificación


Por: Fernando D. Bozzo

En esta ocasión vamos a profundizar en el uso de FoxBin2Prg, sus parámetros, para qué sirve cada uno y en qué casos conviene usarlos, también veremos detalladamente las distintas vistas disponibles, los motivos de haberlas elegido y varios datos técnicos y configuraciones que serán muy útiles para sacarle el mayor provecho, sobre todo para el Diff y el Merge, que son las operaciones más importantes de la revisión y integración de código.


Introducción


FoxBin2Prg se creó como consecuencia de la necesidad de poder contar con algo más potente que el SccText/X.prg que viene con FoxPro, ya que el scctext genera vistas de texto de los binarios (scx, vcx, etc) que son bastante útiles, pero que también contienen información que para el desarrollador es irrelevante y dificulta en cierta medida poder tener un panorama más amplio del código que se está viendo, además de que está limitado a solo comparar código.

En esta época y con la cantidad de herramientas disponibles para casi todas las necesidades y lenguajes desde hace ya un buen tiempo, este era uno de los puntos flojos de Fox y asignatura pendiente, que ya requería una revisión donde se contemplara la integración del código (merge) de distintos desarrolladores de una forma más natural que le permitiera al desarrollador o integrador poder concentrarse más en el código y que evitara tener que mirar en una ventana las diferencias mientras en otra sesión se abren las clases y forms para copiar, pegar y adaptar el código, donde en ocasiones se pueden cometer errores graves.

Casi todo el código generado se puede modificar, siempre que se tenga la precaución necesaria con los metadatos, cuyo significado y uso iré comentando en este artículo.
Los cambios hechos se propagarán al binario generado, quedando en el mismo de forma permanente.

En general los objetos, los métodos y las propiedades están ordenados de forma alfabética, para evitar que se generen diferencias por el reordenamiento que a veces ocurre en el código de las tablas y que puede complicar mucho saber qué cambió realmente.


[2015/04/18 - Actualizado >>]

Configuración inicial en el sistema


Para usar FoxBin2Prg desde el Explorador de archivos, puede crear tres accesos directos a FoxBin2Prg.exe y moverlos a la carpeta "SendTo" en el directorio de su perfil de Windows, así luego puede seleccionar un archivo (pjx,pj2,etc) o directorio con click-derecho y elegir "Enviar a" la opción FoxBin2Prg que desee, y así hacer conversiones al vuelo, luego renombre y edite esos accesos directos como se indica a continuación (asegúrese de que puede ver las extensiones de los archivos):


Nombre----------------------  Right-click/Propiedades/destino-------------
FoxBin2Prg - Binary2Text.lnk  <path>\foxbin2prg.exe "BIN2PRG-SHOWMSG"
FoxBin2Prg - Text2Binary.lnk  <path>\foxbin2prg.exe "PRG2BIN-SHOWMSG"
FoxBin2Prg.lnk                <path>\foxbin2prg.exe "INTERACTIVE-SHOWMSG"

  • Con las opciones "BIN2PRG" o "PRG2BIN" se pueden procesar directorios o archivos individuales, pero para el tipo de conversión seleccionado
  • Con solamente FoxBin2Prg.exe se pueden procesar directorios o archivos individuales para cualquier tipo de conversión
  • Con la opción "INTERACTIVE" se mostrará un cuadro de diálogo al procesar un directorio usando solamente el destino FoxBin2Prg sin las opciones BIN2PRG o PRG2BIN, preguntando qué tipo de conversión se quiere hacer. Esta opción, de hecho, hace innesesarias las dos opciones previas BIN2PRG y PRG2BIN
  • Con la opción "SHOWMSG" se mostrará un mensaje de estado al finalizar la conversión
[<<]


Las Vistas


Uno de los puntos principales a mejorar era las vistas y la mayor cobertura de binarios, y por eso en FoxBin2Prg hay dos tipos de vistas:
  • Una vista de tipo código, pensada para los binarios con programación dentro (clases, forms, menus), donde lo más importante es el código en sí
  • Una vista de tipo XML, pensada para los binarios que contienen datos (DBFs, DBCs) o metadatos (Reportes y Etiquetas) y donde el código no existe o no es lo principal
Las vistas pueden cotener tags especiales con metadatos que son fundamentales para FoxBin2Prg y que no molestan al desarrollador porque figuran como comentarios y se ignoran fácil, pero que al conversor le permite rehacer la información que no puede presentarse como código normal y que es necesaria para poder regenerar una parte de los binarios. Esta información suele ser datos como el timestamp de un registro, o el tipo de archivo referenciado o el orden Z en el caso de algunas clases visuales, pudiendo modificarse en la mayoría de los casos, pero que bajo ninguna condición debe eliminarse, porque causaría la corrupción del binario generado o un error de programa.


Vista de un proyecto (PJ2)


Esta es una vista tipo código, ya que es la que mejor representa el contenido de un proyecto, y tiene algunas secciones que de esta forma se ven y entienden mejor.

La sección <DevInfo> contiene la información de desarrollo que se pone en las pantallas de "Project Info" (con click derecho sobre el proyecto) y "Version", que aparece al pulsar el botón "Build" y luego "Version"



Si hay clases definidas como OLEPUBLIC, entonces también habrá una sección <ServerHead> seguida de tantas secciones <ServerData> como clases OLEPUBLIC se hayan definido. Esta información es fundamental para la registración de los componentes en Windows (objetos COM+ o DLLs) y para permitir que estos sean visibles para todas las aplicaciones del Sistema.



Luego está la parte donde se definen los archivos del proyecto con ADD(archivo) y notar el tag FileMetadata, que contiene información importante del archivo, como el tipo (type), el CodePage (Cpid), la marca de modificación (timestamp) y algunos otros metadatos necesarios de uso interno del binario.




Las siguientes tres secciones secciones son <FileComments>, donde se guardan los comentarios de los archivos, <ExcludedFiles>, donde se indican los archivos excluidos del proyecto (típicamente los archivos .H) y <TextFiles>, donde van los archivos que el proyecto de FoxPro no reconoce correctamente como archivos de texto, aunque realmente lo son, como el config.fpw y algún otro, y que FoxBin2Prg pone automáticamente aquí para que se reubiquen en el apartado de archivos de texto.Esta "reconfiguración" permite que se puedan editar ciertos archivos de texto, que de otra forma FoxPro no permite si se encuentra en la categoría "Otros".





Finalmente está la sección de <ProjectProperties> con las propiedades del proyecto, como el programa principal (SetMain), el icono, el check de "Debug" para habilitar la información de depuración y de "Encripted" para encriptar el código, y el ProjectHook si se definió una clase Hook para el proyecto.
Los tres datos que figuran como comentarios (CmnStyle, NoLogo y SaveCode) son metadatos del proyecto que no tienen una opción en la interfaz, pero que se generan en la tabla PJX.
Probablemente "NoLogo" sea para que al ejecutar un EXE no muestre el logo (ventana de inicio) que suele mostrar mientras carga, aunque no lo comprobé.





Vista de las librerías de clases (VC2) y los Forms (SC2)


Estas vistas son de código, ya que el 99% de la información contenida en la tabla es código.

Estructuralmente los forms y las librerías de clases son casi iguales, y la diferencia principal es que los forms tienen solo dos clases: DataEnvironment y Form.

Aunque el archivo SC2 generado ordena las clases alfabéticamente, luego al ensamblar el binario ubica primero a la clase DataEnvironment, ya que así es como FoxPro lo requiere.

Por lo demás, este archivo tiene las mismas consideraciones que las librerías de clases.


Aunque en los ejemplos siguientes algunos tags salen repartidos en algunas líneas por limitaciones de espacio, realmente ocupan una sola línea en el fichero.

[2014/02/28 - Actualizado >>]
En este caso puse parte del código generado de una librería de clases que contiene una clase ActiveX RichText y que corresponde al primer tag "OLE". La parte de la información OLE (campo "value") se codifica en base 64. En el ejemplo pueden verse algunos metadatos encapsulados dentro del propio objeto, en la etiqueta END OBJECT. En versiones anteriores a v1.19.7 esta información estaba repartida en 2 campos, aquí y en la cabecera del TX2, pero luego se centralizó en el objeto para poder copiar todo junto en una sola operación. [<<]





En esta vista el código está agrupado en clases, de la misma forma que se haría una librería de clases dentro de un PRG. Si la clase tiene algún comentario, éste se pondrá a la derecha del DEFINE CLASS para hacer que su lectura sea natural.

Dentro de los DEFINE CLASS hay un tag de metadata llamado CLASSDATA con información sobre la clase, como la clase de base (BaseClass), el timestamp, la unidad de la escala (Pixels/Foxels) y el ID





Si la clase tiene propiedades o métodos de usuario, sus nombres irán dentro del tag <DefinedPropArrayMethod>, comenzando por una letra (p=property, a=array, m=method) seguido de dos puntos ":", el nombre de la propiedad/array/método y opcionalmente un comentario, si tuviera.

Luego está la definición de las propiedades y valores por defecto

[2014/02/28 - Actualizado >>]
A continuación un ejemplo de clase OLEPUBLIC, donde puede observarse en la cabecera varios tags OBJECTDATA. Estos tags contienen los nombres de los objetos, el ID y el Timestamp y el orden de los mismos determina el ZOrder de los objetos en el form, como se indica en el comentario interno:




Notar que al final de la definición del ADD OBJECT hay un tag END OBJECT con metadatos. Este tipo de tags terminan de definir la clase del objeto agregado, su librería y algunos datos más [<<]

Al final de los objetos, están los procedimientos de la clase con su código.






La diferencia fundamental entre el código de programa "compilable" y el generado por FoxBin2Prg, y que el desarrollador atento habrá podido notar, es que el código no es compilable porque contiene algunos valores que darían error de sintaxis, aunque se entienden igualmente, como ser la propiedad BackColor o Picture de más arriba.

El motivo de asignar algunas propiedades de esta forma y no de la forma correcta se debe a que internamente FoxPro guarda en las tablas los valores de una forma u otra dependiendo si el valor es un valor por defecto, o un valor creado o modificado por el usuario.

Inicialmente había comenzado a hacer una conversión de los valores para que queden de la forma correcta, pero tuve que dejarlo porque los casos especiales eran cada vez más y el desarrollo se hubiera eternizado.

Lo importante es que el desarrollador tenga en cuenta estas particularidades y mantenga el formato por defecto, ya que el objetivo es que se entienda y se pueda rehacer el binario y no que compile. La compilación correcta ya se hará cuando se regenere el binario nuevamente. Este es solo un formato intermedio.



Vista de los Reportes (FR2) y Etiquetas (LB2)

Estas vistas contienen principalmente metadatos (muchos) y muy poco código, por lo que la mejor visualización que pude encontrar es en pseudo-XML. Dentro del mismo hay valores que por no ser interesantes para leer están puestos como propiedades de tag en una sola línea, como Platform, UniqueId, timestamp, etc, y hay otros que por ser más útiles de leer o por tener valores largos o algún bloque de código o de configuración multilínea, están puestos en tags independientes, como picture, tag, tag2, expr y otros.

En este caso se hace un ordenamiento de objetos por vpos y hpos, que son las coordenadas donde se posicionan los distintos objetos en el reporte, como los textbox, líneas, etc. Solo se exceptúan de este ordenamiento los registros especiales, como lo son la cabecera y el entorno de datos, que van al principio y al final respectivamente.

Captura_de_FR2



Para  facilitar la lectura de algunos valores que podrían tener algún interés, también se usan algunas configuraciones de acomodamiento y codificación de datos.

Por ejemplo, el campo <tag2> en este ejemplo tiene información sobre la impresora seleccionada para el reporte, pero como además del texto legible hay códigos de control (chr(0) al 31), se optó por codificarlos usando llaves {}, de forma que un chr(8) se convierte en {8}, así ocupa menos espacio y se puede leer.

En el caso de los campos binarios, la única solución fue codificarlos en base 64 y ponerlos en una sola línea para que ocupen el menor espacio posible y no den problemas con las herramientas de control de código.

En todos los casos, los valores más útiles de leer están puestos al principio, para permitir poder echarles un vistazo rápido y evitar en lo posible el scroll horizontal, y hacia la derecha y fuera del alcance visual están los valores menos útiles para leer.



Vista de los Menús (MN2)


Al igual que las clases y los forms, los menús son casi todo código y muy pocos metadatos.

La estructura generada está inspirada en la que genera FoxPro para los archivos MPR, pero con algunas cosas mejoradas para facilitar su lectura.

Los tags iniciales definen el tipo de menú (MenuType) y su ubicación (MenuLocation), luego está el código de setup delimitado por el tag <SetupCode> y el código del menú, delimitado por <MenuCode>

[2018/09/12 - Actualizado >>]
Valores de MenuLocation: REPLACE, APPEND, BEFORE, AFTER

Valores de MenuType:
1 - Default
2 - BAR or POPUP
3 - Option
4 - Shortcut
5 - MenuBar on top

Respecto de los comandos para generar los menúes, la sintaxis usada es la propia de Visual FoxPro, por lo que la ayuda de VFP puede ser de ayuda para entender cuando usar MENU, POPUP, PAD, MENUBAR, etc.

Lo que hay que tener en cuenta, si se requiere modificar esta información manualmente, es que la forma lógica de anidar los menúes es específica de FoxBin2Prg para mejorar el entendimiento y claridad de las opciones, y agruparlos de forma jerárquica.

Si no se mantiene la agrupación jerárquica, podría generarse un menú inválido o incompleto.
[<<]

Se puede observar como las opciones anidadas dentro de otras están indentadas más adentro y además con una línea de rayas por encima, para separar la opción de las demás y resaltar su ubicación relativa a las anteriores. No es como ver el menú en directo, pero para ser solo código esta disposición visual ayuda bastante.





 Finalmente están los apartados de procedimientos, delimitados por el tag <Procedures> y el código cleanup, delimitado por el tag <CleanupCode>

Los procedimientos están indentados también para facilitar su lectura.

Un dato útil: la cláusula #NAME que se puede usar en los menús para indicar un nombre específico y evitar que FoxPro le asigne uno temporal (como _GGJJSSFGG66), son respetados por FoxBin2Prg al generar los procedimientos, lo que facilita más su lectura.




Vista de las Tablas (DB2)  y Bases de Datos (DC2)


Lógicamente estas vistas no podían ser de código, ya que son metadatos puros, por lo que XML era la mejor opción. Tanto las tablas como las bases de datos tienen una estructura similar.

[2015/04/18 - v1.19.42 >>]
Las tablas tienen un tag principal <TABLE> que engloba todos los apartados de metadatos de la tabla, como los campos e índices y las propiedades de la tabla al inicio.

También hay hay un tag <FIELD_ORDER> que mantiene el ordenamiento original de los campos de la tabla o vista, ya que los nombres de los campos de los tags <FIELD> de tablas y vistas se ordenan alfabéticamente para facilitar el ver las diferencias cuando se hacen cambios. [<<]

En el ejemplo, la tabla pertenece a una base de datos, por lo que tiene información complementaria como datos de validación, triggers, etc.





Las Bases de Datos usan el tag principal <DATABASE> con sus propiedades específicas, y bajo el cual engloba el resto de apartados, como conexiones, tablas, vistas y procedimientos almacenados. A su vez cada apartado contiene su información específica, por ejemplo las tablas contienen sus campos, índices y relaciones y las vistas lo mismo.





Nota: Se debe tener especial cuidado al convertir las tablas y Bases de Datos, ya que FoxBin2Prg no preguntará si se desea realizar la operación, y la hará directamente. En el caso de las tablas, solo se regenerará la estructura de las mismas y sus índices, pero no los datos.


[2015/04/18 - v1.19.42 >>]
Una característica muy útil de las vistas texto de los DBC, de cara a las comparaciones con versiones anteriores, es que todos los miembros se ordenan alfabéticamente, manteniendo esta estructura:
  • Conexiones: Van primero y se ordenan alfabéticamente.
  • Tablas: Van segundo y se ordenan alfabéticamente. Dentro de las tablas, los campos, índices y relaciones también se ordenan alfabeticamente.
  • Vistas: Van tercero y se ordenan alfabéticamente. Dentro de las vistas, los campos también se ordenan alfabeticamente.
  • Stored Procedures: Van al final
[<<]


Consideraciones comunes de las vistas


Todas las operaciones de FoxBin2Prg son seguras, ya que antes de generar un archivo crea un backup del mismo, y en caso de no poder hacerlo se cancela la operación.

En las librerías de clases, los forms y los reportes y etiquetas, el ordenamiento de los objetos se hace para facilitar las comparaciones de código, ya que durante el desarrollo muchos objetos cambian de lugar aunque no se hayan modificado, y eso complicaría demasiado las cosas para el integrador o el desarrollador. Cualquiera que haya trabajado con el SccText.prg que viene por defecto con FoxPro seguramente habrá experimentado estos problemas y sabrá el dolor de cabeza y el tiempo que lleva descubrir las diferencias reales entre bloques de código que se muestran en distintos lugares como diferentes.

Las marcas de timestamp son las más cambiantes y las que más diferencias provocan, y esto se nota especialmente en los reportes, clases o forms con cierta complejidad.

Para evitar esto FoxBin2Prg está configurado por defecto para que las deje vacías, al igual que el UniqueID. En ambos casos se pueden habilitar si se desea.



Parámetros de entrada


La siguiente tabla muestra los parámetros de entrada de FoxBin2Prg, con lo que se pueden cambiar algunas características del funcionamiento.

Donde <params> son:(!=Requerido | ?=Opcional) (@=por referencia | v=por valor), (IN/OUT)
c_InputFile(v! IN ) Ruta absoluta o relativa del archivo a convertir
cType(v? IN ) Para compatibilidad con el SCCTEXT.PRG, indica el tipo de archivo (d=DBC, D=DBF, K=Form, B=Label, M=Menu, R=Report, V=Class)
cTextName(v? IN ) Para compatibilidad con el SCCTEXT.PRG, es el nombre del archivo de Texto a generar
lGenText(v? IN ) Para compatibilidad con el SCCTEXT.PRG, .T.=Generar Texto, .F.=Generar Binario
cDontShowErrors(v? IN ) '1' para NO mostrar errores con MESSAGEBOX
cDebug(v? IN ) '1' para depurar en el punto del error (solo modo desarrollo)
cDontShowProgress(v? IN ) '1' para NO mostrar la barra de progreso
cOriginalFileName(v? IN ) Para los casos en los que inputFile es un nombre temporal y se necesita el nombre correcto original (por ejemplo: dentro de los archivos PJ2 y de las cabeceras TEXTO)
cRecompile(v? IN ) Si se indica un Path, recompilará el binario desde el mismo. Si se invoca desde SCCAPI, será Verdadero por defecto y si no será Falso por defecto
cNoTimestamps(v? IN ) '1' para limpiar los Timestamps en texto y binarios. Util para minimizar las diferencias en operaciones de Diff y Merge

c_InputFile es el único parámetro obligatorio, donde se especifica la ruta del archivo de entrada y en base al cual se generará el de salida. Si la entrada es un binario, la salida será texto y viseversa.

Los parámetros del 2 al 4 (cType, cTextName y lGenText) son para usar solamente por SourceSafe y están implementados desde la versión v1.19.6

Si ocurriera algún error se genera un archivo .ERR y se muestra un mensaje avisando de ello, pero podría suceder que en un proceso batch no se quiera esto, sino solo generar un LOG, en cuyo caso hay dos seteos que se pueden usar: cDontShowErrors y cDebug

cDontShowErrors = '1' hará que no se muestren mensajes de error que requieren la intervención del usuario, y cDebug solo conviene usarlo para depurar, ya que genera un archivo .LOG con información de depuración algo más detallada.

La generación del LOG también se puede habilitar creando un archivo foxbin2prg.log en el mismo directorio donde se haya puesto el PRG o el EXE de FoxBin2Prg

Algunas herramientas SCM (de control de código fuente) copian los archivos a los que se está haciendo Diff o Merge en ubicaciones temporales o con nombres temporales, lo que puede hacer que FoxBin2Prg genere algunos nombres de archivo mal. Por ejemplo, todas las vistas texto tienen una cabecera de este tipo:



El nombre del archivo se toma del parámetro c_InputFile, si éste fuera temporal (ej: c:\temp\_frrdde77dd.mnx), entonces eso quedará reflejado en la cabecera también.

En el caso de los proyectos (PJ2) es peor, ya que el nombre del proyecto se usa en varias partes dentro del archivo, lo que incluso puede hacer que lo generado sea inválido.

En ambos casos la única solución posible pasa por usar el parámetro cOriginalFileName, pasando el nombre y ruta que realmente tendría el archivo en su ubicación original, y este parámetro FoxBin2Prg lo usa para arreglar todas las referencias internas a los nombres del archivo.

El parámetro cRecompile sirve para desactivar la compilación luego de la regenerecación del binario, o bien para indicar la ruta desde la que se debe recompilar.

El motivo de este parámetro es permitir optimizar la velocidad de regeneración de binarios, ya que si se tiene automatizado el proceso de generación del ejecutable y previamente se regeneran los binarios desde sus versiones texto, entonces ya se estarán compilando los binarios para hacer el EXE, por lo que se podría desactivar la compilación de FoxBin2Prg y ganar todo el tiempo que implica recompilar estos archivos nuevamente.




[2015/05/10 - v1.19.43 >>]

Configuración


En el directorio de instalación hay un archivo de configuración llamado foxbin2prg.cfg.txt donde están detallados los valores por defecto en Inglés y Español, y más abajo están las configuraciones modificables.
Este archivo, si se le quita la extensión .txt (foxbin2prg.cfg), se puede usar como modelo para crear configuraciones personalizadas por directorio, aprovechando la herencia de CFGs entre directorios padre/hijo.

FoxBin2Prg.cfg - Si no se proporcionan valores, estos son los predeterminados Detalle y valores soportados
extension: xx2 Las extensiones por defecto de FoxBin2Prg terminan en '2'
ShowProgressbar: 1 1=Mostrar barra de progreso por defecto en procesamiento multi-archivo, 0=No mostrar PB
DontShowErrors: 0 Mostrar mensajes de error por defecto
NoTimestamps: 1 Vaciar Timestamps por defecto para minimizar diferencias
Debug: 0 No Activar <archivo>.Log por defecto
ExtraBackupLevels: 1 Por defecto 1 BAK es creado. Con esto puede crear más .N.BAK, o ninguno si indica 0.
ClearUniqueID: 1 0=Mantener UniqueID, 1=Borrar Unique ID. Util para Diff y Merge
OptimizeByFilestamp: 0 1=Optimizar la regeneración de archivos dependiendo del timestamp de archivo, 0=No optimizar (más seguro si se usa para merge o para editar el tx2)
ClearDBFLastUpdate: 1 1=No mantener la fecha LastUpdate de los DBFs, 0=Mantenerla
RemoveNullCharsFromCode: 1 1=Quitar NULLs del código fuente, 0=Dejar los NULLs en el código
RemoveZOrderSetFromProps: 1 1=Quitar ZOrderSet de las propiedades, 0=Dejar ZOrderSet en las propiedades
Language: (auto) Lenguage de los mensajes mostrados y Logs. EN=Inglés, FR=Francés, ES=Español, DE=Alemán, No definido = AUTOMATICO [DEFAULT]
XXX_Conversion_Support: N 0=Sin soporte, 1=Generar solo TXT (Diff), 2=Regenerar BINARIOS (Merge), 4=Generate TXT with DATA for DIFF (DBF only)
PJX_Conversion_Support: 2 Ver XXX_Conversion_Support
VCX_Conversion_Support: 2 Ver XXX_Conversion_Support
SCX_Conversion_Support: 2 Ver XXX_Conversion_Support
FRX_Conversion_Support: 2 Ver XXX_Conversion_Support
LBX_Conversion_Support: 2 Ver XXX_Conversion_Support
MNX_Conversion_Support: 2 Ver XXX_Conversion_Support
DBC_Conversion_Support: 2 Ver XXX_Conversion_Support
DBF_Conversion_Support: 1 Ver XXX_Conversion_Support >> FoxBin2Prg tiene soporte bi-direccional para convertir DBF, pero no mantiene los datos. Usar con cuidado.
DBF_Conversion_Included: * Si DBF_Conversion_Support:4, se pueden indicar múltiples máscaras de archivo: www,fb2p_free.dbf
DBF_Conversion_Excluded: Si DBF_Conversion_Support:4, se pueden indicar múltiples máscaras de archivo: www,fb2p_free.dbf
UseClassPerFile: 0 0=Una archivo librería tx2, 1=Múltiples archivo.clase.tx2, 2=Múltiples archivo.clasebase.clase.tx2, incluyendo DBCs y sus miembros
RedirectClassPerFileToMain: 0 0=No redireccionar a archivo.tx2, 1=Redireccionar a archivo.tx2 cuando se seleccione archivo.clase.tx2
ClassPerFileCheck: 0 0=No verificar la inclusión de archivo.clase.tx2, 1=Verificar la inclusión de archivo.clase.tx2


[<<]


Configuración de extensiones


Por defecto, las extensiones de FoxBin2Prg terminan en 2 (pj2, sc2, vc2, etc), pero si fuera necesario que la extensión fuera otra, se puede configurar usando el archivo foxbin2prg.cfg (en el zip se adjunta uno renombrado con guión bajo al final), e indicando la equivalencia de extensiones requeridas.

La reconfiguración de extensiones se hace con estas líneas dentro del archivo cfg (ejemplo para SourceSafe):

extension: vc2=vca
extension: sc2=sca
extension: pj2=pja
...(otras)


Hay otros parámetros configurables descriptos dentro de este archivo de configuración, somo ser:

DontShowProgress => Para no mostrar la barra de progreso
DontShowErrors => Para no mostrar mensajes de error
NoTimestamps => Por defecto ya está desactivado internamente
Debug => Permite generar un LOG para saber que se hace
ExtraBackupLevels => Cantidad de backups a hacer (max:9) Por defecto 1 internamente
ClearUniqueID => Permite dejar vacío el ID de los registros (se recomienda poner en 1 para minimizar diferencias)
XXX_Conversion_Support => Permite cambiar el soporte a distintos tipos de archivo. 0=Sin soporte, 1=Solo texto (como scctext), 2=bidireccional (regenera binario), 4=Generar DB2 con DATOS para DIFF (sólo DBFs)


Nota importante:
El soporte por defecto de los DBFs está configurado en 1 (generar solo texto) para evitar pisar las tablas de datos por error al regenerar todos los binarios.
Para activar la regeneración del DBF y sus índices, se debe descomentar la línea DBF_Conversion_Support = 1 y cambiarle el valor a 2 para que quede DBF_Conversion_Support = 2.



[2015/04/18 - Actualizado >>] 

Exportación de datos para Diff


Si se quieren exportar los datos de tablas pequeñas para poder ver los cambios entre distintas versiones, se puede poner DBF_Conversion_Support: 4 en el archivo de configuración, y para que esta configuración no afecte a todas las tablas, ya que algunas pueden tener muchos datos, es mejor moverlas a otro directorio --o subdirectorio de DATOS-- y ponerles su propio CFG, aprovechando la capacidad de multi-configuración introducida en la versión v1.19.25 


Cuando se exportan datos de tablas para poder llevar un control de sus diferencias, típicamente tablas chicas de configuración o similar, puede ser muy útil establecer un ordenamiento de esos datos, para minimizar las diferencias al comparar y que no aparezcan registros mezclados como si se hubieran hecho muchos cambios. Para esto se puede crear un archivo de configuración individual por tabla, con la nomenclatura nombretabla.dbf.cfg, con los siguientes valores dentro:

DBF_Conversion_Order: <C_Expression>  Indica una expresión válida de Fox para ordenar los campos. Por ejemplo: DBF_Conversion_Order: cust_no
DBF_Conversion_Condition: <C_Expression> Indica una expresión válida de Fox para filtrar los campos. Por ejemplo: DBF_Conversion_Condition: cust_no > 10

[<<]


Nota:
Dentro del foxbin2prg.cfg están todas las configuraciones con los valores por defecto y el detalle de cada una.



Capitalización de nombres de archivo


En el zip de FoxBin2Prg se incluye un programa para normalizar la capitalización de los nombres de archivo llamado filename_caps.exe
Si este programa y su archivo de configuración filename_caps.cfg se copian junto a FoxBin2Prg.exe, se utilizará automáticamente y se usarán las reglas de capitalización que se hayan indicado en su configuración.

La configuración por defecto es la siguiente:

*---------------------------------------------------------------------------------
* FILENAME_CAPS.CFG
*
* FORMATO DE MÁSCARAS:
* --------------------
* filemask=Filename.Ext:FilenameCAP.ExtCAP
*     Donde:  Filename    ==> Es el nombre del archivo
*             Ext         ==> Es la extensión
*             FilenameCAP ==> (U)ppercase, (L)owercase, (P)roper, (M)atch, (N)one
*             ExtCAP      ==> (U)ppercase, (L)owercase, (P)roper, (M)atch, (N)one
*
* EJEMPLOS DE MÁSCARAS:
* ---------------------
* filemask=*.PDF:U.L    ==> Convierte los archivos PDF a <NOMBREARCHIVO.pdf>
* filemask=*.DOT:L.U    ==> Convierte los archivos DOT a <nombrearchivo.DOT>
* filemask=*.PRG:C.L    ==> Convierte un archivo específico a <Nombrearchivo.ini>
* filemask=EJEMPLO.ini:C.U ==> Convierte un archivo específico a <Ejemplo.INI>
*
* IMPORTANTE:
* -----------
* LAS CONVERSIONES SE REALIZAN EN EL ORDEN QUE SE PONGAN, COMENZANDO POR ARRIBA.
*---------------------------------------------------------------------------------
 

filemask=*.*:N.L

Lo que hace por defecto es respetar la capitalización del nombre de los archivos y pasar las extensiones a minúsculas.

Este programa es bastante básico y sencillo, pero las opciones disponibles permiten una configuración suficiente para la mayoría de los casos. Además se puede usar en solitario para otras herramientas, como CVS u otras herramientas SCM, antes de hacer el checkin, ya que ayuda a evitar los errores posteriores que suelen ocurrir cuando se intenta hacer checkin, diff o merge de archivos con distinta capitalización.
SourceSafe es uno de los que no es afectado por esto, ya que es solo para Windows, pero para las herramientas SCM multiplataforma sí es un problema.



Palabras finales


El zip de FoxBin2Prg contiene algunas herramientas relacionadas, hechas para mejorar la productividad cuando se requiere tratar muchos archivos con pocos clicks, lo que incluye 4 scripts vbs (Convert_VFP9_PRG_2_BIN.vbs, Convert_VFP9_BIN_2_PRG.vbs, Normalize_FileNames.vbs y VFP9_FoxBin2Prg.vbs) a los que se les puede crear un acceso directo y poner estos accesos en la carpeta "SendTo" del directorio del perfil del usuario (c:\Documents and settings\usuario\SendTo), lo que permitirá seleccionar directorios o archivos y usar el click derecho para enviarlos al programa o script elegido.



En una próxima nota hablaré sobre la integración y configuración de FoxBin2Prg con algunas herramientas SCM.


Hasta la próxima!


Artículos relacionados:
FoxBin2Prg, el sucesor mejorado del scctext
FoxBin2Prg: Guía rápida de uso y configuración
FoxBin2Prg: Descarga de VFPx