Exe muy grande
Juan Roa
Mauricio R. Molinero
Miguel Canchas
Busca el konxise a mi dio grandes soluciones cuando mi exe pasaba mas de 30 MB lo reducia al 10%...y todavía con VFP 9.
Formatearon mi maquina y perdi mi instalador…nunca mas lo volvi a usar/encontrar
MK
ZeRoberto
Miguel Canchas
Que fue lo que pidio ¿? Comprimir o seguridad ¿? , además el konxise con que lo descomprimes ¿?
MK
Carlos Miguel FARIAS
Si es por un problema de desempeño a nivel procesador, si se comprime externamente, no creo que se logre mejorar mucho, porque el mismo proceso de descompresión puede involucrar un tiempo significativo.
La división en exe y dll es una opción interesante, la he probado, y he podido separar buena parte del código fuera de la corriente principal.
No lo hice para reducir el tamaño del programa al momento de ejecutar, lo hice para poder modularizar rutinas por separado, en el caso de requerirse la actualización de parte de la aplicación, solo se reemplaza el modulo afectado, sin tener que reemplazar, partes que están ya funcionando, y además, una mejore reaprovechamiento de aplicaciones que usen los mismos módulos.
Entonces, puse todas las rutinas, funciones y procedimientos utilitarios en un exe.
Las rutinas de gestion de menu estandar en otras, con funciones incorporadas para recibir "modificaciones" al vuelo de los menues, según los subsistemas.
En otro/s modulo/s, todas las clases no visuales de acceso a datos (o sea, el modelo) y bibliotecas no visuales de funciones comunes para manejo de datos.
En otro modulo, toda la vista (formularios y clases visuales).
Donde mas ahorras es en las clases visuales (las otras, generalmente, es código plano, se reaprovecha mucha parte común pero las reglas de cada tabla, son de cada tabla o de un conjunto de tablas, hay que hilar muy fino, y no ahorras mucho.
Pero en la parte visual, es impresionante la cantidad de código que puede reutilizarse.
En mi caso. Defino los botones más comunes a nivel de clase, cada boton tiene el código que hace a su funcionalidad intrinseca, cuando lo necesito en un formulario, lo agrego y ese boton en ese formulario, sabe a que metodo del formulario llamar para cumplir su fin.
Todo lo inherente al boton (imagen, propiedades, tamaño, código en el clic, etc.) solo ocupa lugar una vez (en la biblioteca), en cada formulario que lo usa, una simple referencia.
En mi caso defino botones para navegar por las tablas, guardar, crear nuevo registro, actualizar, borrar, salir, buscar, etc.
Si tenes 50 formularios con un mismo boton, el espacio requerido a lo sumo es el de codificar dos botones, en lugar de los 50 si lo definieras en cada uno.
Pero eso no termina ahi.
Se puede definir un formulario base, donde se incorporan todos los métodos y propiedades comunes a todos los formularios.
En mi caso, en ese formulario base, incorporo el timer de cierre por no uso estando al frente, propiedades que trabajan como banderas para saber si en el formulario se ha hecho un cambio o no, si esta en modo creando, etc.
Y después, se pueden agregar subclases de formularios con caracteristicas comunes a diversos grupos, y se sigue ahorrando espacio.
Otra pauta. Para todos los controles que manejan datos (textbox, editbox, check, etc.) creo una clase base, donde ya les defino por ejemplo tipo de letra y en el método gotfocus, le hago guardar el valor actual del campo en una propiedad (o en el comment), luego, en el lostfocus, comparo el valor al entrar con el valor al salir. Si son distintos, activo la propiedad bandera del formulario que indica que hice un cambio.
E invoco al metodo, Revisa banderas y cambia estado botones (que tambien es parte del código de la clase formulario) y este método, habilita/deshabilita los botones correspondientes.
Esas son algunas ideas de como reducir el tamaño de la aplicación por uso apropiado del diseño OOP, que tiene otra ventaja más importante que reducir el tamaño del programa, y es, reducir el tiempo de poner a punto el código (ya lo probastes antes) y en caso de algún bug, corregis una vez y el arreglo se propaga a toda la aplicación con una simple recompilación.
Saludos: Miguel, La Pampa (RA)
tomcrux
Hola
Una manera de disminuir el tamaño del proyecto es quitar la información
de depuración que se incluye en el EXE al generarlo.Para ello es necesario hacer lo siguiente:
- Abrir el proyecto con VFP.
- Seleccionar en el menú la opción Proyect>Project Info
- En la ventana que se abre seleccionar el tab Project
- Destildar la opción "Debug Info".
- Compilar nuevamente el EXE, se podrá notar un cambio en el
tamaño del mismo.
Algo mas:
Los archivos .scx, .frx, .vcx son en realidad tablas que VFP
maneja con información de los formularios, reportes y clases respectivamente.
Al ser tablas es posible contengan registros que han sido eliminados por el
mismo VFP con el comando DELETE. Estos registros ocupan espacio y por lo tanto
pueden aumentar notablemente el tamaño de nuestros ejecutables.
Para eliminar tales registros se puede abrir estos archivos como si fueran una tabla con el comando USE de manera Exclusiva por ej.:
USE MiFormulario.scx EXCLUSIVE
Luego ejecutar el comando:
PACK.
Aplicar esto a todos los archivos del proyecto del tipo scx, frx, vcx, etc.
Por lo que tengo entendido al seleccionar (con el proyecto abierto) la opción de menú Project>Clean up Project, se quitan los registros que fueron borrados con DELETE del archivo de proyecto .pjx, de no ser asi se le puede aplicar lo explicado anteriormente.
Posteriormente generar nuevamente el ejecutable, este debería de cambiar su tamaño y ser más chico que el anterior.
Espero estos comentarios te sirvan.
Saludos desde
Córdoba, Argentina
Tomas Cruz.