28 de febrero de 2017

GETPICT() con miniaturas

Artículo original: GETPICT() with thumbnails
http://weblogs.foxite.com/vfpimaging/archive/2007/06/27/4199.aspx
Autor: Cesar Ch.
Traducido por: Ana María Bisbé York


Esto va por Koen Piller.

He visto mucha gente en los foros preguntando sobre la posibilidad de abrir el diálogo GETPICT() mostrando las miniaturas en lugar de los nombres de archivos de imágenes.

Sólo por diversión, hice algunas pruebas simulando algunas teclas, y ¡ funciona ! Ejecute las 3 líneas siguientes en WinXP

oShell = CREATEOBJECT("Wscript.Shell")
oShell.SendKeys("{TAB}{TAB}{TAB}{TAB}{TAB}{DOWN}{DOWN}{DOWN}{DOWN}{ENTER}")
GETPICT()

Como puede ver, he utilizado la función SendKeys de WSH. En este enlace, puede encontrar todos los códigos, si desea utilizar esta técnica para cualquier otro propósito: http://msdn2.microsoft.com/en-us/library/system.windows.forms.sendkeys(vs.71).aspx

Esto fue probado solamente en mi PC de trabajo, con WinXP Profesional. probablemente no trabaje de esta forma en otros Sistemas Operativos, así que vaya con cuidado, y si desea utilizar este código, verifíquelo primero.

Estoy casi seguro de que debe existir otra forma, probablemente más segura de hacerlo. ¿Usted sabe?

26 de febrero de 2017

El usuario siempre tiene la razón

Artículo original: The User is Always Right
http://doughennig.blogspot.com/2006/03/user-is-always-right.html
Autor: Doug Hennig
Traducido por: Ana María Bisbé York


A veces, nosotros, los desarrolladores de aplicaciones nos tornamos un tanto arrogantes. Creo que todos diseñamos las aplicaciones para que sea lo más fácil de usar posible; pero no siempre lo logramos. Y cuando los usuarios se meten en problemas por algo que han hecho, nuestra primera reacción es culparles:

  • Eso estaba escrito en el archivo de ayuda, ¿No lo ha leído?
  • No oprima ese botón a no ser que sepa lo que está haciendo.
  • ¿Por qué hizo eso?

Me he encontrado culpable de esto mismo recientemente. En Stonefield Query (http://www.stonefieldquery.com) comienza un proyecto nuevo oprimiendo el botón New Project en la barra de herramientas y seleccionando el directorio donde debe ir el archivo proyecto. Los archivos del proyecto son especificados en un archivo llamado SFQuery.INI, el que es creado después de oprimir el botón OK en el cuadro File. Trabaja genial.

Bueno, casi. Un desarrollador reportó un error en su proceso. El dice que no sólo ha seleccionado la carpeta deseada, también ha cambiado el nombre de un archivo a algo como MyProject.INI. Por supuesto, la aplicación está buscando SFQuery.INI, no lo encuentra, y recibe el mensaje de advertencia. Mi reacción (no ante el desarrollador, no soy tan descortés) fue de pensar ¿Por qué el usuario esperaba que trabajara? Yo no podría cambiar el nombre de una DLL de Microsoft World y luego sorprenderme de que dejara de funcionar.

Sin embargo, agregamos algún texto a nuestro archivo de ayuda documentando que nombre del archivo no podía ser cambiado, porque de lo contrario, nadie podría ejecutarlo. De esta forma llegamos a los Axiomas del desarrollo de aplicaciones de Doug.

Axioma # 1: La gente no lee

Otro desarrollador llegó al mismo problema. ¿Será que eran compañeros de habitación en el instituto? Cuando decimos que esto está documentado, replican que no han leído la documentación. ¿Por qué debía? Cuán complejo es oprimir en el botón New, seleccionar una carpeta y oprimir OK?

Entonces, arreglamos el problema al ignorar que el nombre de archivo entrado por el usuario y utilizando solamente la carpeta al crear SFQuery.INI. Fin del asunto.

Tenemos una llamada de un desarrollador, durante la cual apareció el Axioma # 2 de Doug.

Axioma # 2 La gente no es buena para comunicarse

El dijo que la función New nunca trabajó. Me encanta ese nivel de detalles. Veamos, "no trabaja". ¿Significa que ha recibido un mensaje de error? ¿Tengo que usar el Administrador de tarea de Windows para determinar un lazo interminable? ¿El monitor se hizo pedazos y cayeron trozos de vidrio en su cara? No, el solamente no creó el proyecto. Cuando le preguntamos un poco más, entonces se dio cuenta de que había escrito un nombre de archivo nuevo (el tristemente famoso MyProject.INI); pero cuando verificó en la carpeta, no existía el archivo, sino otro llamado SFQuery.INI

Entonces se hizo la luz. No era culpa del usuario, era culpa mía. ¿Por qué cuando lo que queremos es que el usuario seleccione una carpeta, mostramos el diálogo Archivo. La razón es que queremos que el usuario vea si el proyecto Stonefield Query ya existe en esa carpeta o no. Si ve el SFQuery.INI en la lista de archivos, no lo podría saber que ya lo había hecho. Esta no es una buena razón, sin embargo, hicimos finalmente lo correcto: cambiamos el diálogo por el de Seleccionar carpeta. Ahora no hay confusión en lo que necesita hacer el usuario.

Un segundo ejemplo: un usuario se quejó de que se le habían perdido unos informes. Luego de un trabajo propio de detectives, se dio cuenta de que los había borrado accidentalmente: el pensó modificar el informe; pero oprimió Eliminar, por error. Pero... ¿cómo pudo haber un accidente? Preguntamos al usuario con la típica pregunta ¿Está seguro?, entonces debe seleccionar "Yes" para confirmar la eliminación. Ah; pero es que habíamos olvidado el Axioma # 1. El problema es que Windows tiene tan acostumbrados a los usuarios ha seleccionar "Yes" sin leer los mensajes cada vez que aparece un diálogo, que ya es una costumbre. Existen varias soluciones para esto:

  • Reescribir el texto para que "Yes" signifique no eliminar el archivo. Probablemente no es la mejor elección.
  • Brindar una función Deshacer para el usuario pueda recuperar el informe eliminado. Nos gustó esta idea; pero sólo funciona si el usuario se da cuenta inmediatamente de lo que ha hecho. No ayudaría al usuario.
  • Complicar la selección de la función Eliminar. Justo ahora, el botón Eliminar está detrás del botón Editar. Haciendo una retrospectiva es evidente que se podía pensar que ocurriría un desastre. Puede ser que no deba estar en la barra de herramienta y solamente en el menú, ya que es muy raro decidir eliminar un informe comparado con la creación o modificación.

Conclusión: Necesito dedicar más tiempo a pensar algunas cosas desde la perspectiva de usuarios inexpertos. Y recordar el Axioma # 3:

Axioma # 3 El usuario siempre tiene la razón

No necesariamente en cómo comunican sus ideas (vea Axioma # 2) pero al menos en su intento.

Para ver más ideas sobre este escrito, vea: http://www.codinghorror.com/blog/archives/000550.html.

23 de febrero de 2017

Utilizar # DEFINE para navegar por el código

Artículo original: Use # DEFINE to navigate your code
http://www.ml-consult.co.uk/foxst-33.htm
Autor: Mike Lewis
Traducido por: Ana María Bisbé York


Un consejo sencillo que le permitirá recorrer grandes bloques de código mucho más fácil.

Recientemente un usuario nos pidió que le realizáramos un trabajo de mantenimiento en una aplicación Visual FoxPro. El programa incluía un único archivo PRG con más de 2,500 líneas de código. Nos quisimos desmayar al ver que el programador original no intentó siquiera dividir la lógica en pequeños módulos; lo había escrito como una única rutina monolítica.

Actualmente el estilo de programación no se presta para el mantenimiento. Lo ideal hubiera sido tomar tiempo para reestructurar el programa en procedimientos y funciones separadas; pero desafortunadamente, esto no fue posible.

Nosotros, sin embargo, dimos con una vía sencilla para navegar por esa monstruosa pieza de código. Nos dimos cuenta que el programa estaba hecho aproximadamente de 25 secciones lógicas. Cada uno de estos trozos de código realizaba una tarea particular. Al inicio de cada una de estas secciones, colocamos una directiva #DEFINE. Esto incluyó un identificador significativo que describe el propósito del código que le continúa como estos ejemplos:

#DEFINE Validate_Input@@
...@@ 
#DEFINE Calculate_Residue@@
...@@ 
#DEFINE Cleanup@@
...

La cuestión sobre estas directivas # DEFINE está en que ellas se muestran en la ventana Vista del documento (Document view) del menú Herramientas (Tools) (vea Figura1). Por consiguiente, tenemos una vía muy sencilla para acceder a cualquier sección de código, solamente con un clic del ratón.

Figura 1: Ventana Vista del documento. Las entradas con la marca # roja y grande son las directivas #DEFINE que se colocaron en el programa.

Si no ha utilizado la ventana de Vista de documento con anterioridad, definitivamente vale la pena tomar un momento para conocerla (está disponible en VFP7.0 y superior). Puede abrirla desde la Barra de herramientas Estándar (Standard toolbar) o desde el menú Herramientas (Tools). Su trabajo principal es mostrar los nombres de todos los procedimientos, funciones y métodos definidos en un archivo de programa, formulario o clase visual. Al hacer clic en uno de estos nombres, Visual FoxPro lo lleva directamente al código de la rutina en cuestión. (En el caso de los formularios y clases, debe hacer clic en el área de diseño para llenar inicialmente la ventana Vista del documento).

Opcionalmente, la ventana puede mostrar también las directivas #DEFINE y otras directivas de compilación. Estas opciones (que están activas de forma predeterminada) pueden encontrarse en el menú contextual que aparece al hacer clic derecho en la ventana. Esta característica nos facilitó la tarea de recorrer nuestro enorme archivo PRG.

Algo especialmente agradable de esta técnica es que una vez que se completó el trabajo de mantenimiento, no tuvimos que quitar las directivas #DEFINE. Como el resto de directivas del compilador, estas no impactan en tiempo de ejecución, y no afectan el rendimiento al dejarlas en el código.

Mike Lewis Consultants Ltd.

9 de febrero de 2017

CMD VFP - Mantenimiento de Tablas y Comandos Externos

Hemos visto muchas veces la necesidad de realizar un Mantenimiento de nuestra Tabla en un Sistema ya finalizado y suele suceder que no tenemos instalado el Visual FoxPro en esa PC, y tenemos que recurrir a muchas alternativas y muchas veces no es un buen modo de trabajar. Debido a muchas consultas que veía en la red me anime en aportar este pequeño modulo que se puede incorporar a sus propios sistemas y usar cuando sea necesario, solo en nivel de Mantenimiento.

Que hace este Pequeño Modulo trabaja con Tablas libres, simplemente usted busca la tabla a trabajar y si dicha tabla a sido dañada por falla de fluido eléctrico, la puede reparar sin problemas, o quizás hacer un pequeño mantenimiento de la misma tabla, ya sea reindexar, o modificar la estructura del mismo.

Además si desea realizar algún comando adicional lo puede hacer desde la Ventana Comandos sin necesidad de tener instalado el VFP, es decir lo puede hacer desde su sistema.

Descarga

Pueden descargar la clase v.1.70 desde el siguiente enlace: cmdvfp_1.70.rar

Jean Pierre Adonis De la Cruz Garcia
Pisco, Perú