RE:Alguien usa el Pelles C?
Trabajar con DLLs para la interfaz con el usuario, no es la manera correcta de trabajar en Windows, es un error que venimos arrastrando desde FiveWin para Clipper a 16 bits.
En un curso de migración de aplicaciones de FW de 16 a 32 bits al que asistí con René Flores, nos enseñó que hemos vivido engañados todo el tiempo con el tema de las DLLs para guardar las pantallas de nuestros programas.
En las primeras versiones de FW para Clipper de 16 bits, erróneamente aprendimos que todas las pantallas de la interfaz con el usuario van en DLLs y eso no es lo correcto, ninguna aplicación de Windows llámese Word, Excel, Acrobat, etc tiene en una DLL las pantallas de la interfaz con el usuario, las pantallas van "fundidas" dentro del mismo EXE, y debemos dejar el tema de los DLLs para meter alli CODIGO FUENTE de funciones comunes a nuestros aplicativos.
Este error de concepto se dió en Clipper de 16 bits por una deficiencia grave, pero entendible del compilador de Clipper..... NO TIENE COMPILADOR DE RECURSOS ( y no tiene porqué tenerlo, es un compilador para aplicaciones MS-DOS, no es de esperar que tenga un compilador de recursos para Windows).
Por comodidad, con FW para Clipper de 16 bits, se utiliza el Borland Resource Workshop para editar la interfaz con el usuario, el Workshop incluye un compilador de recursos, sin embargo, es tedioso durante el proceso de desarrollo de una aplicación hacer 2 procesos de compilación: una para el código fuente y otra para los recursos.
Por un lado, hay que compilar el código fuente en PRG usando Clipper, luego hay que compilar el código fuente de los recursos usando el BRC (Borland Resouce Compiler) para luego encontrarte con la sorpresa de que el enlazador Blinker no soporta enlazado de recursos y hay que recurrir un enlazador externo para "pegar" los recursos dentro del EXE generado con blinker, y todo eso desde un fichero .BAT o RMK para Clipper, complicado para el programador novato, luego, lo mas conveniente y práctico era trabajar con la DLL.
¿ Tiene algo de malo trabajar con la DLL ? , pues no, sin embargo puede presentar algún problema en tiempo de ejecución en caso de falla de la aplicación, a mas de uno le habrá pasado que cuando el programa EXE casca, la DLL se queda pegada en memoria y hay que reiniciar el ordenador para cerrar la DLL abierta.
Otro problema de la DLL es que al ser un archivo externo de enlazado dinámico no se carga totalmente en memoria, solo se carga en memoria lo que se va necesitando, cuando se va necesitando, con lo cual cada vez que hay necesidad de un recurso nuevo, hay que hacer un acceso a disco para traerlo y cargarlo en memoria, en aplicaciones de red, donde el EXE y su DLL se ponen en un disco compartido del servidor, esto provoca tráfico en la red porque cada vez que se necesita un recurso del DLL y este no se encuentra cargado en la memoria, hay que ir a buscarle al disco de la red, si bien con las velocidades de red que tenemos actualmente y los gigas de memoria RAM esto no es problema, tampoco es la forma correcta de trabajar.
La forma correcta de trabajar, es "pegando" los recursos dentro del EXE, con esto tienes la ventaja de que una vez cargado el EXE, tienes cargados los recursos, liberas memoria de trabajo al no tener que tener una DLL abierta con los recursos (cosa que se agrava si utilizar recursos de Borland, entonces necesitas DOS DLLs abiertas) y tu aplicación tendrá un mejor desempeño y será mas fácil de distribuir, un solo EXE, sin DLLs para las pantallas.
¿ Como haces para "pegar" un RC dentro del EXE ?, deja que las herramientas trabajen por tí, a 32 bits con Harbour, tienes herramientas que te permiten hacer el proceso de compilado y enlazado de una manera visual, tienes el VerCE, el AJMake, el xMate, el XEdit, el xHarbour Builder, etc.
Estas herramientas te generan los EXE a 32 bits, tu solo tienes que indicar de manera visual la ubicacion de tu (x)Harbour, de tu Borland C++, de tu código fuente Y DE TU FICHERO.RC, el proceso de compilación que ejecutan estas herramientas hará la compilación del RC y el linkado de los recursos dentro del EXE, tu no tienes que preocuparte de nada.
Así que mi consejo es: Olvidate de los DLLs para las pantallas, y mete los recursos dentro del EXE.
