[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 archivo
s, <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.
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
