Categoría: Programación

El verano. Esa época en la que crees que por fin tendrás algo de tiempo libre para hacer cosas como actualizar el blog, y resulta que acabas estando más ocupado que durante el curso. Y para colmo, las 2 o 3 horas muertas que tienes al día se van al traste cuando haciendo limpieza encuentras un CD lleno de ROMs y emuladores de consolas de 16 bits. Emuladores que misteriosamente son compatibles con el mando cableado de XBox 360. Razones más que de sobra para volver a machacar píxeles como antaño…

En fin. Entre rato y rato, y debido a, como viene siendo costumbre desde hace 5 años, estar contratado por cierta empresa postal cuyo nombre no quiero mencionar, he vuelto a la programación para no terminar de oxidarme del todo. La razón ha sido la necesidad de actualizar el callejero del que se dispone en la oficina para corregir las cartas que llegan mal direccionadas; actualmente se disponía de unas hojas mecanografiadas con una antigüedad de unos 20 años en las que se habían ido escribiendo y tachando una larga lista de correcciones (nuevas calles, cambios de domicilio, etc). Pues bien, decidí recopilar todos los datos más actuales y, ya puestos, compilarlos en una base de datos bien estructurada, y no un documento de Word u hoja de Excel como suele ser la costumbre. Los problemas no habían hecho nada más que empezar.

Bien. En la oficina se disponen de varios PCs, y uno de ellos es de uso exclusivo por el personal de reparto. La base de datos estaría almacenada únicamente en este equipo, con la “gracia” de contar con las siguientes peculiaridades:

1. Sistema operativo Windows XP. Vale, no está mal, yo mismo sigo usándolo.
2. Ausencia total de cualquier .NET Framework (hala, a olvidarse de tener las cosas fáciles).
3. Únicos programas del paquete Office 2003 instalados: Word y Excel (adiós, base de datos de Access editable por los usuarios).
4. Ausencia total de permisos de instalación de aplicaciones y de acceso al Panel de Control (para terminar de arreglar las cosas, vamos).

O lo que es lo mismo: adiós C#, adiós SQL Server, adiós Rapid Application Development. Pero bueno, no estaba todo perdido.

Dándole vueltas a qué API podía usar para hacer algo con un GUI mínimamente decente, me acordé de mis inicios con VC++ y la programación gráfica: MFC. Si compilaba el proyecto con las librerías en modo estático (Link as static library), el tamaño final del ejecutable se incrementaría notablemente, pero me ahorraría el problema de tener que comprobar si las DLLs ya estaban presentes en el sistema. Por otra parte, el problema del acceso a la BD también estaba solucionado; aunque no podía acceder al Panel de Control y por tanto añadir un origen de datos ODBC, sí podía conectar en tiempo de ejecución gracias al driver de Microsoft Access que todas las instalaciones de Windows XP traen por defecto.

Ya sólo quedaba ponerse manos a la obra: se crea una nueva aplicación MFC basada en diálogos (nada de modelo documento-vista, no es necesario complicarse la vida) y se añade el soporte para bases de datos:

Creamos un objeto CDatabase y lo abrimos mediante Open, especificándole una cadena de conexión válida en nuestro caso.

Y una vez abierto, operamos mediante objetos CRecordset, que podemos instanciar directamente para pasarles consultas SQL, o crear clases derivadas de éste para añadir funcionalidades que vayamos a usar frecuentemente.

Como viene siendo costumbre, adjunto un pequeño programa de ejemplo que demuestra las funcionalidades explicadas. Aunque el uso de MFC ha decaído bastante desde el nacimiento de .NET, espero que a alguien le sirva de provecho 🙂