Mostrando entradas con la etiqueta configuración. Mostrar todas las entradas
Mostrando entradas con la etiqueta configuración. Mostrar todas las entradas

domingo, septiembre 14, 2014

PlasticSCM: Cómo configurar la replicación entre repositorios Plastic locales y remotos

Por: Fernando D. Bozzo


[05/06/2015 - Actualizado con nuevo apartado de Exportación e Importación manual]

Suena complicado el título, como algo de la NASA, pero realmente no lo es.

En resumen: En Plastic, la "replicación" se refiere a la sincronización entre 2 repositorios, que es lo mismo que sincronizar 2 bases de datos, donde todos los datos nuevos que se han agregado en una de ellas se pasan a la otra, y viceversa, para lograr que ambas tengan lo mismo.

Estas bases de datos pueden ser locales, remotas o mezcla de ambas. En el caso de un repositorio remoto, puede ser tanto la PC o Portátil de al lado, como un servidor en otra planta o en otro edificio o ciudad.



¿Qué diferencia hay entre usar la Replicación y no usarla?


La replicación es simplemente una redundancia de repositorios, una forma de tener más de una copia de lo mismo y en ciertos casos es la única forma de poder trabajar con otras personas. Por ejemplo, cuando se trabaja con un Portátil que se puede llevar al cliente, y no se disponga de una conexión al repositorio principal (obviamente, siempre que el Portátil no sea el repositorio principal), entonces se hace necesario trabajar offline, o sea, con un repositorio local para poder ir protegiendo los cambios y mantener un historial de los cambios, que más tarde se sincronizarán con el repositorio central, que está en una PC de casa o de la oficina.

En el caso de no usar replicación de repositorios, se estará usando un único repositorio siempre, que estará todo el tiempo actualizado con lo último y no requerirá ninguna sincronización. Siempre estará la posibilidad abierta para crear otro repositorio en otro PC y hacer replicación.

Ahora, centrándonos en las diferencias, más allá de la sincronización en sí, la única diferencia notable es respecto de la eliminación de changesets, ya que si necesitamos eliminar un changeset o una rama por haberla creado mal, por ser innecesaria o por lo que sea, trabajando con un único repositorio esto es algo que se hace en un solo paso (se borra y listo), pero trabajando con replicación, se debe hacer esa eliminación en cada uno de los repositorios replicados, ya que si solo se hace en uno, al sincronizar se volverá a restablecer el/los changesets y ramas eliminadas, ya que los repositorios que tengan esa información se la pasarán a los que no la tengan.

Al final es algo simple de solucionar, pero es importante saber cómo funciona.



¿Qué ventaja tiene usar la Replicación?


La ventaja principal, es que con un par de clicks podemos hacer un "backup" en otro ordenador conectado a la red o a Internet, cosa que si a nuestro ordenador principal le pasa algo, al menos tenemos la tranquilidad de que tenemos una copia en otro ordenador, y es difícil que se estropeen 2 ordenadores a la vez.

A colación de esto, ¿recuerdan cuántas personas han aparecido en los foros diciendo que habían perdido todo o parte del trabajo (nada menos que los fuentes), y que sólo tenían, con suerte, un EXE para descompilar? ¿o los que se les ha estropeado algún binario (en general un form) con el que estuvo trabajando todo el día?

Espero que con lo fácil que es esto, ustedes no sean nunca esas personas, porque con esta facilidad que ofrece un DVCS y en varios casos sin coste (como este), ya no hay excusas. La comodidad es muy peligrosa en estos temas.




Configuración de una vista de sincronización


Veamos un ejemplo práctico de una replicación de un servidor Plastic local, por ejemplo, la PC o Portátil que usamos para desarrollar, y un servidor externo, que bien podría ser otro PC en la red o en Internet.

Nota: En mi caso, la PC local de trabajo es un Windows 7 virtualizado que llamé win7u, y el servidor es un PC físico con Ubuntu Linux llamado fer-desktop. En ambos casos, ustedes deben reemplazar los nombres de PC por los vuestros, así que las imágenes a continuación son orientativas. Para saber el nombre de vuestro PC, pueden abrir la ventana de comandos DOS, escribir SET <Enter> y ver una variable que dice COMPUTERNAME=NombreDeVuestroPC.



1) Lo primero es abrir la vista de Sincronización de repositorios, en el panel izquierdo, donde podemos observar 2 paneles verticales; el superior con los nombres de las "vistas" de conexiones y el de abajo con las conexiones de esa vista:




2) Luego añadimos una vista (de conexiones), que en este caso es una agrupación de una o más conexiones que se agruparán bajo un nombre identificativo a elección:




Una vez agregada la vista, ya aparece en la lista:




3) Ahora agregamos el origen de la conexión, que es el PC con el repositorio de origen, por ejemplo, nuestro PC o Portátil de trabajo (recordar, win7u es mi PC, ustedes pongan el suyo!):




 Una vez seleccionado el PC, el puerto y el repositorio, ya aparece el origen creado en la vista:




4) Ahora asociamos el destino de replicación, que puede ser otro repositorio en la misma PC o en otra que esté visible en la red o en Internet, en mi caso será fer-desktop, pero ustedes pongan la suya.

Cuando clickeen "Buscar" es posible que les pida las credenciales para conectarse al repositorio indicado, así que deberán indicarlas, y opcionalmente pueden marcar el check para "Recordar credenciales como un perfil de conexión", que luego se podrá acceder desde la opción "Preferencias" del panel izquierdo:

Nota: En el caso de que el repositorio externo sea de Internet o fuera de nuestra empresa o casa, conviene usar siempre una conexión SSL para mejorar la seguridad, en cuyo caso el servidor debe indicarse como ssl://ServidorRemoto:8088, donde ServidorRemoto puede ser una dirección URL o una IP.





5) Una vez puestos los datos del PC/servidor destino y puerto, se mostrarán los repositorios encontrados en el mismo (solo los que se tenga acceso), para seleccionar uno y aceptar:




6) Ya podemos "Refrescar" la conexión para que verifique si hay algo que sincronizar, por lo que hacemos click-derecho en la conexión deseada:




7) Si hay algo, como en este ejemplo, se mostrará qué hay, y si son cambios entrantes o salientes, siendo los entrantes los que actualizarán nuestro repositorio origen (normalmente el local) y los salientes los que se exportarán al repositorio destino (normalmente externo):




8) Si hay cambios, sincronizamos todo:




9) Se mostrarán las ramas que se sincronizarán y se da la oportunidad de cambiar algunos parámetros de la sincronización:




10) Si hay cambios para sincronizar, se mostrará un avance del proceso:




11) Hasta que finalice:




12) Una vez terminada la sincronización, se mostrará un mensaje de estado:




13) Respecto del check que había comentado cuando agregamos el repositorio destino, que permitía guardar las credenciales como un Perfil de conexión, estos datos se pueden acceder desde la opción de "Preferencias" del panel izquierdo, de donde se pueden modificar, agregar o eliminar perfiles, e indicar si el perfil es de conexión "Automática" o "Manual":


Respecto de elegir conexión Automática o Manual, la decisión se debe basar en si el repositorio a conectarse está todo el tiempo disponible (siempre online) o no (a veces offline).



[Actualizado. 05/06/2015 >>]

Exportación e Importación manual de repositorios


Plastic permite exportar o importar los repositorios, uno a uno, de forma manual por medio del comando cm desde la ventana de comandos. El formato es abierto y se basa en el mismo formato que usa git, con lo cual también se puede usar para importar o exportar en git.


Exportación:

La sintaxis para exportar es la siguiente:

cm fast-export repositorio@servidor:8087 [archivo-destino.dat]

Si no se indica el nombre del archivo destino, se llamará "fast-export.dat", y si existiera, se le irá agregando 1, 2, 3, etc.


Este es un ejemplo de uso en Linux (muy similar a Windows):

cm fast-export FoxUnit@fer-desktop:8087 ./FoxUnit.dat


Importación:

La sintaxis para importar es la siguiente:

cm fast-import repositorio@servidor:8087 archivo-a-importar



Más información en la web oficial:
https://www.plasticscm.com/documentation/technical-articles/kb-fast-import-fast-export.html
[<<]



Notas finales

Este artículo pretendió explicar de forma rápida como configurar una replicación, pero no es extensivo, y hay unos cuántos parámetros y combinaciones interesantes para ver, como por ejemplo la posibilidad de replicar un origen a múltiples destinos y otras opciones, que les dejo para que les investiguen ustedes.

Espero que les haya sido útil.


Hasta la próxima! :D


Artículos relacionados:
PlasticSCM: Opciones de conectividad, transporte del código fuente y backup


sábado, agosto 23, 2014

PlasticSCM: Opciones de búsqueda y visualización de ramas y changesets

Por: Fernando D. Bozzo

Cuando se comienza a trabajar con ramas, al poco tiempo se puede convertir en un frondoso árbol donde a veces es difícil poder ver una rama particular y sus relaciones, porque es cruzada por varias otras que en principio no nos interesa ver.

Una de las cosas más importantes que se debe conocer, cuando se trabaja con una herramienta SCM o DVCS, es poder visualizar lo que se quiere de distintas formas, para tener un mejor control sobre lo que se está haciendo o viendo.

En este artículo veremos varias de ellas, y les recomiendo elegir estas opciones al menos una vez para conocerlas y ver su utilidad.

Nota: Todas las vistas permiten trabajar desde ellas. No solo son para visualizar.


Todas las vistas se seleccionan desde el panel izquierdo, el cuál está siempre visible:




Vista del Explorador de ramas


Esta es una vista típica de las ramas de un equipo de desarrollo donde, como se puede observar, cuesta un poco poder ver solo las ramas marcadas en amarillo:





Panel derecho del Explorador de ramas


Con el botón Navegador se puede habilitar o inhabilitar el panel derecho, que tiene varias opciones interesantes:




Apartado: Propiedades


Dentro de este apartado podemos ver información sobre el changeset o rama seleccionada, además de que desde aquí podemos modificar los comentarios:




Apartado: Opciones de visualización


Dentro de este apartado podemos controlar varios aspectos de lo que se muestra en el Explorador de ramas, incluso opciones de filtrao por fechas o niveles de hijos desde el changeset 0.

La mayoría de las opciones son simples y se pueden entender a primera vista, pero hay un par de opciones que no son tan obvian y que requieren algo de explicación, y que son las de debajo de todo: Activar modo de edición de visibilidad y Activar edición de disposición.


Activar modo de edición de visibilidad

Permite ocultar/mostrar ramas: Se elige esta opción, se marcan las ramas a ocultar y se desmarca esta opción para finalizar. Todavía no me tocó una situación donde requiera esto.

Nota: Cuando se elige esta opción, se muestra una explicación de uso debajo.


Activar edición de disposición

Esta opción permite reorganizar las ramas, para poder agruparlas de una forma más útil que la forma por defecto, por ejemplo, acercando entre sí las ramas que tienen relación directa.

Nota: Cuando se elige esta opción, se muestra una explicación de uso debajo.


La forma se uso es simple: Se marca esta opción, se elige la rama que se quiere mover (solo hacia arriba/abajo, ya que izquierda/derecha es controlado por la fecha/hora de la rama según su columna), se mueve la rama con las flechas de cursor y se vuelve a desmarcar esta opción para que queden los cambios guardados.



Nota: Si no se llegara a ver todo el panel completo y apareciera recortado en altura, seguramente el problema sea la resolución de pantalla, que debería ser como mínimo de 1280x1024 para poder ver las opciones completas.


Búsqueda rápida


El cuadro superior-derecho permite escribir para hacer un filtrado en cuando se pulsa <Enter>.

Por ejemplo, si escribiéramos tarea-025, la vista anterior resaltaría en amarillo todas las ramas que contengan ese texto en su nombre, marcando la rama seleccionada en naranja, permitiendo la navegación por las mismas con las flechas de navegación.




Nota: Una búsqueda que a veces puede ser útil, es la búsqueda por changeset, que da un único resultado. En ese caso la forma de buscar es usand la nomenclatura cs:nn , por ejemplo para buscar el changeset 51, escribiríamos cs:51 <Enter>


Opciones del Explorador de ramas


Si hacemos click-derecho sobre una rama y elegimos la opción Explorador de ramas, podemos ver las siguientes opciones:




Opción: Ir a la base de la rama


Nos permite ir al changeset de la rama padre de donde se creó esta rama, y que es a donde apunta la flecha gris fina de cada rama.



Opción: Mostrar ramas seleccionadas en un nuevo diagrama


Si quisiéramos ver una rama (o varias) por separado, sin el ruido de las que no nos interesan, las podemos marcar con CTRL+Click, al igual que se hace para elegir varios archivos en el explorador de archivos, luego hacemos click-derecho sobre una de las ramas seleccionadas y elegimos la opción en cuestión.

Si eligiéramos las 2 ramas en amarillo del principio, se abriría una nueva vista filtrada así:




Opción: Mostrar ramas seleccionadas y relacionadas en un nuevo diagrama


Si quisiéramos ver una rama (o varias) y las  ramas directamente relaciondas por separado, las podemos marcar con CTRL+Click, al igual que se hace para elegir varios archivos en el explorador de archivos, luego hacemos click-derecho sobre una de las ramas seleccionadas y elegimos la opción en cuestión.

Por ejemplo, si quisiéramos ver las ramas relacionadas a la tarea-025 del primer ejemplo, con sólo seleccionar esa rama y eligiendo esta opción se abriría una nueva vista filtrada así:





Opción: Mostrar merges pendientes para las ramas seleccionadas en un nuevo diagrama


Si alguno entiende lo que muestra este diagrama y cuándo y porqué lo hace, por favor, que me lo explique :)




Opción: Mostrar diagrama personalizado de las ramas seleccionadas...


Esta opción muestra un cuadro de diálogo que permite indicar algunas de las opciones anteriores y algunas condiciones de filtrado adicionales:





Vista de Ramas


Esta es una vista de texto con información adicional como los comentarios de las ramas, muy útil en algunos casos, que también permite seleccionar ramas y operar con ellas para hacer Diff, Merge y otras operaciones.

Nota: La rama con el changeset actual siempre se muestra en negritas.


Esta es la vista plana, donde de paso se puede ver que no comentar las ramas quita información útil a la derecha:



Y esta es la vista jerárquica (solo para ramas Plastic nativas, las de GitHub y otros repositorios pueden no verse bien anidadas):



Misma vista, pero abriendo el panel derecho de detalles con el icono marcado en rojo:




Búsqueda rápida


El cuadro superior-derecho permite escribir para hacer un filtrado en tiempo real.

Por ejemplo, si escribiéramos tarea-025, la vista plana anterior filtraría todo lo que contenga ese texto en cualquiera de las columnas mostradas, comentarios incluidos:


Nota: Las columnas permiten ordenar la información mostrada, si se cliquea en ellas.



Vista de Changesets


Al igual que la vista de Ramas, esta es una vista de texto que permite ver rápidamente los changesets con sus comentarios, fecha de creación y otros datos, y que también permite seleccionar changesets y operar con ellos para hacer Diff, Merge y otras operaciones.



Búsqueda rápida


El cuadro superior-derecho permite escribir para hacer un filtrado en tiempo real.

Por ejemplo, si escribiéramos fidel, la vista plana anterior filtraría todo lo que contenga ese texto en cualquiera de las columnas mostradas, comentarios incluidos, y ese es otro motivo para escribir cosas útiles en los comentarios:


Nota: Las columnas permiten ordenar la información mostrada, si se cliquea en ellas.




Vista de Etiquetas


Esta es otra vista de texto que permite ver rápidamente las etiquetas con sus comentarios, fecha de creación y otros datos, y que también permite operar con ellas para hacer Diff, Merge y otras operaciones.



Búsqueda rápida


El cuadro superior-derecho permite escribir para hacer un filtrado en tiempo real.

Por ejemplo, si escribiéramos 1.1, la vista plana anterior filtraría todo lo que contenga ese texto en cualquiera de las columnas mostradas, comentarios incluidos:


Nota: Las columnas permiten ordenar la información mostrada, si se cliquea en ellas.



Vista de Shelves


Esta es otra vista de texto que permite ver rápidamente las etiquetas con sus comentarios, fecha de creación y otros datos, y que también permite operar con ellas para hacer Diff, Merge y otras operaciones.



Búsqueda rápida


Tiene el mismo funcionamiento que las demás vistas de texto.


Comentarios finales


Conocer todas estas vistas y opciones de filtrado, es fundamental para poder navegar por la información que brinda una herramienta SCM o DVCS y para poder realizar operaciones con la misma.

Poder hacer todo esto es una de las mayores ventajas que aporta trabajar con estas herramientas, donde la mayoría de opciones son prácticamente imposibles si se trabaja a la antigua usanza.

Esto es lo que permite poder manipular el código de una aplicación completa con un control total y a distintos niveles de detalle.


Hasta la próxima!

jueves, junio 26, 2014

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

[2015/04/18: Actualizado hasta FoxBin2Prg v1.19.42]

Por: Fernando D. Bozzo

En el caso de que no sepas de qué va esto porque sea la primera vez que entras aquí, te lo resumo:

FoxBin2Prg es un programa Open Source que forma parte del proyecto VFPX en CodePlex, esta hecho en Visual FoxPro 9 SP2 y pretende sustituir a TwoFox y al scctext.prg que viene con Visual FoxPro y que se usa para realizar la conversión de los binarios de VFP 9 (scx, vcx, etc) a texto estilo-prg, con la diferencia de que FoxBin2Prg es bidireccional, o sea que desde el texto puede regenerar los binarios.

Aunque este programa es un PRG, también está compilado como un EXE para que se pueda vincular a otras herramientas, como el explorador de archivos o herramientas SCM (control de código fuente) como Plastic, SourceSafe, etc., además el EXE es m´s rápido y tiene incluido todos los archivos necesarios.


Breve reseña del problema a resolver


Un problema de los binarios de Visual FoxPro (scx, vcx, etc) es justamente ese, que su código fuente está metido en tablas DBF (sí, los scx, vcx y demás son DBF renombrados) y esto dificulta enormemente poder trabajar con ellos de forma más libre y sobre todo dificulta poder integrarlo en herramientas de control de código fuente, y en parte esto es una de las causas de que muchos programadores FoxPro no usen herramientas de control de código.
A todos los efectos, desde fuera estos arhivos son binarios, y como tales, son susceptibles de corromperse, y de hecho lo hacen, y cuando lo hacen hay una alta probabilidad de perder todo o parte del código fuente.

Lo que se hizo en su momento (años 90) para minimizar este problema, fue convertir estos binarios a representaciones de texto, para lo cual, el más conocido de esos programas (scctext.prg) hacía un volcado de los campos memo internos de los forms, clases y demás a un txt con extensión sca, vca, etc, pero casi sin ningún formateo que permitiera poder verlo mejor y analizarlo, y así ha sido hasta la llegada de un nuevo programa en enero de 2014, FoxBin2Prg, que justamente pretende cubrir todas esas carencias mediante la generación de vistas modificables de texto que son un 99% código PRG para los binarios que tienen código fuente y que cualquier programador Fox entiende; y pseudo-XML para los demás, pero con un detalle importante: con este texto generado se puede volver a reconstruir el binario original, lo que permite realizar todas las operaciones de manejo de código que se suelen hacer con una herramienta SCM, incluyendo el diff y el merge, que es la operación más compleja en un entorno de desarrollo.


¡La Capitalización de nombres de archivo importa!


Es necesario conocer exactamente qué hace FoxBin2Prg, para luego poder elegir cómo, cuándo y por qué hacerlo.

FoxBin2Prg no solo genera una vista de texto de los binarios y regenera los binarios desde la vista de texto, sino que también capitaliza los programas que convierte para normalizarlos, para lo que se integra con otro programa específico llamado filename_caps.exe, y que también puede usarse por separado.

La importancia de esta capitalización radica en que cuando se usan ciertos programas o sistemas multiplataforma para gestión de código, como CVS, Subversion, Git, Plastic y otros, un archivo.así es distinto que un Archivo.ASÍ, ya que Windows es prácticamente el único Sistema Operativo que no distingue entre ambos, pero Mac, Linux, Unix, BeOS y otros sí, y los consideran como dos archivos distintos.

Estas diferencias en los nombres de archivo pueden provocar toda clase de problemas, desde errores que impidan trabajar o sincronizar con el SCM (por ejemplo GitHub, CVS, etc), hasta la sustitución de archivos por versiones erróneas.


¿Qué contiene el proyecto?:


El proyecto contiene todos los archivos fuentes, pero para su uso sólo se requieren ciertos archivos, que varían dependiendo de si se usa el EXE o el PRG.


Versión EXE (más compacta y rápida):
  • FoxBin2Prg.exe => Conversor principal con todo dentro
  • FoxBin2Prg.cfg => Configuración del Conversor



Versión PRG (requiere más archivos y es algo menos rápida): 

  • FoxBin2Prg.prg => Conversor principal
  • Props_*.txt => 27 Archivos para evaluación y ordenamiento de propiedades

Archivos necesarios en ambas versiones:
  • FoxBin2Prg.cfg.txt => Archivo modelo para usar de configuración del conversor
  • filename_caps.exe => Gestor de capitalización de nombres de archivo
  • filename_caps.cfg => Configuración del Gestor de capitalización
  • Convert_VFP9_BIN_2_PRG.vbs => Script para conversión masiva de Binario a Tx2, y mostrando mensaje de finalización de proceso. (Opcional, se puede reemplazar por FoxBin llamado con el parámetro BIN2PRG)
  • Convert_VFP9_PRG_2_BIN.vbs => Script para conversión masiva de Tx2 a Binario, y mostrando mensaje de finalización de proceso. (Opcional, se puede reemplazar por FoxBin llamado con el parámetro PRG2BIN)
  • Normalize_FileNames.vbs =>  Script para capitalización masiva de archivos
  • VFP9_FoxBin2Prg.vbs => Script para invocar a FoxBin2Prg.exe, pero mostrando mensaje de finalización de proceso. (Opcional, se puede reemplazar por FoxBin llamado con el parámetro SHOWMSG)


Internacionalización (localización)


Desde la versión v1.19.38 la selección de lenguaje es automática y se basa en la función VERSION(3), y se puede cambiar en el archivo de configuración foxbin2prg.cfg usando la nueva opción "Language".

Los valores adminitos son: ES  (Español), EN (Inglés), DE (Alemán) y FR (Francés) y si se indica cualquier otro o el predeterminado no es uno de estos, se seleccionará automáticamente Inglés (EN).



Vale, y ahora, ¿cómo se usa?


Para usar FoxBin2Prg desde el Explorador de archivos, puede crear 3 accesos directos de FoxBin2Prg.exe (click-derecho / crear acceso directo) y moverlos a la carpeta "SendTo" en su perfil de Windows (que normalmente está en C:\Documents and settings\<usuario>\SendTo o en C:\Users\usuario\<usuario>\SendTo), así podrá "enviar" el archivo elegido (pjx,pj2,etc) a la opción seleccionada, y hacer conversiones-al-vuelo, luego renombre esos accesos directos y modifíquelos como sigue (asegúrese de que puede ver las extensiones de archivos del sistema):

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

  • Con la opción "BIN2PRG" o "PRG2BIN", puede procesar directorios o archivos individuales
  • Con FoxBin2Prg.exe solamente, puede procesar archivos individuales
  • Con la opción "INTERACTIVE", un mensaje de confirmación será mostrado cuando termine, y los errores encontrados serán mostrados automáticamente también


¡Atención! No copiar los programas en la carpeta SendTo, sólo deben ponerse los "accesos directos" de los programas, ya que internamente tienen la ruta completa del programa original.


Casos de uso:

- Si se quiere convertir sólo 1 archivo binario a texto, entonces se debe hacer click-derecho en el archivo (scx, vcx, etc) y elegir Enviar a => FoxBin2Prg

- Si se quiere convertir sólo 1 archivo texto a binario, entonces se debe hacer click-derecho en el archivo (sc2, vc2, etc) y elegir Enviar a => FoxBin2Prg

- Si se quieren convertir los archivos binarios a texto de un directorio, entonces se debe hacer click-derecho en el directorio y elegir Enviar a => FoxBin2Prg - Binary2Text

- - Si se quieren convertir los archivos de texto a binario de un directorio, entonces se debe hacer click-derecho en el directorio y elegir Enviar a => FoxBin2Prg - Text2Binary

- Si se quieren capitalizar los archivos de un directorio, entonces se debe hacer click-derecho en un directorio y elegir Enviar a => Normalize_FileNames



El caso de uso normal sería el siguiente:

- Se trabaja un form, una clase, etc., en una sesión de FoxPro hasta que se termine y se cierra el form

- Clear all en la ventana de comandos

- En el explorador de archivos se elije el form (o clase, etc) y se convierte a texto

- Luego se elige el archivo de texto recién generado y se vuelve a convertir a binario

Listo!



Configuración

El Gestor de Capitalización por defecto está configurado para respetar la capitalización de los nombres de archivo y pasar las extensiones a minúsculas, y normalmente con eso es suficiente. Pero si se quiere controlar más, mirar dentro del archivo filename_caps.cfg que está más detallado y con algunos ejemplos.

La configuración por defecto es esta:

filemask=*.*:N.L

El Conversor por defecto está configurado para generar las extensiones xx2, soportar la conversión bidireccional de todas menos los DB2 (por seguridad, pero se puede cambiar) y dejar vacíos los Timestamps e ID's de registro.

[2015/04/18 - v1.19.42 >>]
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
DropNullCharsFromCode: 1 1=Quitar NULLs del código fuente, 0=Dejar los NULLs en el código
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

[<<]



Exportar datos para Diff (DBF_Conversion_Support:4)


Con esta configuración se pueden exportar los datos de las tabla, y con las siguientes configuraciones se puede hilar más fino, eligiendo qué tablas sí, cuáles no, y con qué ordenamiento y filtro.

DBF_Conversion_Included: <filemask>[ ,<filemask> [ , ... ] ]
DBF_Conversion_Excluded: <filemask>[ ,<filemask> [ , ... ] ]

Ejemplo de las máscaras <filemask>, separadas por coma:

DBF_Conversion_Included: PET*.*, ??ME.DBF, ???.DBF, ?.*


Si se quisieran filtrar los datos de una tabla llamada mitabla.dbf  para solo exportar los registros cuyo campo is_initial = .T. y se desea exportar ordenado por cust_order, habría que crear un archivo cfg en el mismo directorio de la tabla, así:

mitabla.dbf.cfg:
DBF_Conversion_Order: cust_order
DBF_Conversion_Condition: is_initial = .T

Nota: En DBF_Conversion_Order se puede poner cualquier expresión FoxPro válida para ordenar


[2015/04/18 - v1.19.42 >>]

Generar una clase por archivo (UseClassPerFile:1 ó 2)


Desde la v1.19.37 se puede configurar FoxBin2Prg para generar las clases de una librería en archivos independientes, si se pone el seteo UseClassPerFile:1 en foxbin2prg.cfg, lo que generará archivos con la nomenclatura de TwoFox (libreria.nombreclase.tx2)

Por defecto, si luego se elige uno de esos archivos de clases (libreria.nombreclase.tx2) y se intenta regenerar el binario, se creará una nueva librería archivo.clase.vcx, que en algún caso puede ser útil si se quieren separar algunas clases de una librería.

Desde la v1.19.42 se puede usar el nuevo valor "2" para UseClassPerFile, que a diferencia del anterior genera archivos con una nomenclatura libreria.clasebase.nombreclase.tx2 que es más explícita y por tanto más útil para poder identificar rápidamente las clases visuales de las no visuales, por ejemplo.

Además con "2" se aplicará esta división en archivos individuales también a los DBC, donde la nomenclatura de los miembros será nombrebdd.tipo.nombre.dc2, por ejemplo: nombrebdd.connection.cnxoracle.dc2 o nombrebdd.table.clientes.dc2

En el caso de que que siempre se quiera que se regenere la librería original, sin importar cuál de sus partes se elija, se debe usar el seteo RedirectClassPerFileToMain:1, lo que redirigirá las peticiones al archivo principal.

Cuando se ensamblan las librerías desde las partes archivo.clase.tx2, no se verifica si esa parte realmente corresponde a la librería, lo ue permite anexar nuevas clases con solo ponerle la nomenclatura adecuada.

En el caso de que se quiera asegurar de que solamente las clases originales se ensamblen en la librería VCX, se puede usar el seteo ClassPerFileCheck:1, lo que comprobará que los archivos encontrados figuren en la lista interna del archivo principal de cabecera. 
[<<]

Está generando un archivo de error .ERR, ¿que hago?


Pues lo primero es abrir ese archivo y ver qué error muestra. Es probable que diga algo como esto:

Error 1098, El archivo [C:\DESA\foxbin2prg\tst1.sct] no está soportado

Y es correcto, porque se debió elegir el que termina en 'x' (scx, vcx, etc)

Para cualquier otro tipo de error, por favor, reportármelo así lo analizo.



Una cosa más


Aquí no hablé de la integración y uso con ninguna herramienta SCM, porque la idea era que conozcan el uso de este programa en solitario, y porque no todo el mundo pretende usar una herramienta SCM (control de código fuente)

Para el uso integrado con otras herramientas, ya he comentado sobre la integración con PlasticSCM en esta nota sobre su instalación y en esta nota sobre su uso en ramas, y en futuras notas podrá ser con otras herramientas SCM.



Eso es todo!



Si te interesa conocer más detalles, aquí unos links:
- FoxBin2Prg: El sucesor mejorado del scctext
- FoxBin2Prg: Detalle de vistas, datos de uso, configuraciones y más
- FoxBin2Prg: Descarga de VFPx
- FoxBin2Prg: Descarga de GitHub

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

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!

domingo, febrero 02, 2014

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