FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
michal,
Cita:
Pregunto: 1- ¿Que versión de Delphi utilizas?. 2- ¿Que versión de Windows utilizas?. Te comento: 1- Lo viable en función de las características de hardware que mencionadas es Windows XP Professional x32 y Delphi 7. 2- El tamaño del ejecutable en memoria lo puedes disminuir al cargar los formularios dinámicamente como se sugirió en el Msg #4. 3- La opción de usar DLLs dinámicas para disminuir el tamaño del ejecutable en memoria es factible, revisa estos links: Cita:
Nelson. |
#2
|
|||
|
|||
Algo más
La mayoría de las PCs usan winXp sp3 de 32 bits y las más pobres usan win2k sp4
No uso Delphi sinó C++Builder 2009 aunque también tengo la versión 6. Ya yo he logrado introducir los formularios en las DLLs pero no logro que una función, declarada en la DLL, poderla asociar a un botón que pertenezca a un formulario que esté dentro de esa misma DLL. Ese es principal problema de usar la solución de las DLL, que para ser sincero es la que más me gusta. La otra la de crear formularios con sus componentes y luego destruirlos dinamicamente, al final el ejecutable crece igual y eso es lo que trato de evitar, debido a que mientras más grande es, más se tarda en cargar la aplicación. Y la opción de comprimirlo con el upx empeora la situación, pues demora mucho más la carga, debido a que primero tiene que descomprimirlo para luego ejecutarlo. |
#3
|
||||
|
||||
De todas formas, dices que vas por la mitad del proyecto. Cualquier optimización (sea de tamaño o de rendimiento) no debería realizarse hasta haber completado el programa. Una vez lo termines, ya sí, puedes ponerte a ver si consigues reducir tamaños.
De todas formas, el consejo de no crear todos los formularios y TData automáticamente es bueno. Lo que no sé es por qué está activado por defecto, cuando personalmente creo que debería ser al revés. |
#4
|
||||
|
||||
michal,
Cita:
Te comento: 1- Te sugiero probar si un ejecutable en C++ Builder 6 con 40 formularios es menor en tamaño a uno creado con C++ Builder 2009, en Delphi se presenta el caso de que las versiones superiores a Delphi 7, generan ejecutables de mayor tamaño por la inclusión de nuevas librerías y/o cambios a las tradicionales. 2- En términos generales la información de creación de DLLs del Msg #6 es aplicable con sus correspondientes adaptaciones a C++ Builder. Espero sea útil Nelson. |
#5
|
|||
|
|||
Por intentar aportar algo se me ocurre que podrias en caso que al final no encuentres mas solución partir tu aplicación en varios modulos pero en lugar de hacerlos dll hacer propios ejecutables. No es una solución óptima ni mucho menos y ademas no se adapta a todas las situaciones. Pero si algún grupo de ventanas de la aplicación comienzan con una modal que debe de cerrarse antes de continuar con otra cosa bien puede ser un exe aparte (al que quizas deban de pasarsele algunos parámetros ciertamente).
Haciendo esto bien es verdad que es posible que acabes con un grupo de ejecutables que al sumar sus tamaños ocupen mas que tú ejecutable individual. Repito de nuevo que son mejores las otras opciones que están apuntando pero igual te vale la pena valorar lo que propongo. Pienso también que 90 ventanas son muchas ventanas para una aplicación. ¿Seguro que realmente no tienes varias aplicaciones compiladas como una sola? Por ejemplo si tienes una aplicación desde la que se gestiona a los trabajadores de una empresa con sus nominas clientes, tareas pendientes etc, ademas de alamcenes con mercancía, albaranes facturación.... igual es mejor tener una aplicación de gestión de almacén, otra de facturación, otra de nomina, y otra de control de personal, aunque todas trabajen contra la misma bd. |
#6
|
||||
|
||||
un form es una clase con sus metodos y puedes crear el form en una dll con sus metodos y luego simplemente creas el form dinamicamente en tu ejecutable y podras acceder a sus metodos sin problemas. Eso si, para no liarte creas un .h donde declaras los eventos que usaras, metes lo que quieras que se haga en cada evento en el cpp de la dll y luego incluyes ese .h a tu main y con eso puedes acceder a todo.
|
#7
|
|||
|
|||
La situación es sumamente simple y le están dando demasiadas vueltas.
Uno de mis sistemas más complejos tiene 72 formularios (sin contar principal, opciones, etc), y precisamente la que comentas es la que creo yo que es la mejor forma de gestionar las ventanas. 1, plantéate el uso de bpl’s en lugar de dll’s, la razón es que los bpl’s son exactamente iguales a las dll’s, solo que añaden el uso de RTTI y son un poco más estables al cargar y descargar de memoria (con la única desventaja de no ser estándar, es decir solo tu aplicación u otra aplicación Builder/Delphi, podrán consumirla). 2, en la dll o bpl, crea una unit (.cpp,.h), en la que contendrás las funciones que se exportaran e iniciaran los formularios, también estas pueden recibir parámetros o punteros de la BD, por ejemplo (a costa de la estandarización, cosa que no te debe preocupar si tu aplicación será la única que consuma la dll/bpl). Cada función debe ser declarada en él .h de la siguiente manera: Código:
extern "C" __declspec( dllexport )void __stdcall miFuncionDLL( TIBDatabase *punteroEjemplo ); 2.1, ya dentro de esta función creas el formulario y le pasas lo que necesites, en este caso “punteroEjemplo” que es el puntero del componente de la BD con el que se conectara tu componente de tabla o query. 3, ya en la aplicación principal en cualquier evento de botón va el siguiente código: Código:
void __fastcall TForm1::Boton1Click(TObject *Sender) { String rutaDLL = "mi ruta de dll"; HINSTANCE li = FileExists( rutaDLL ) ? //comprobamos que la dll exista LoadLibrary( rutaDLL.c_str() ) //si existe cargamos la dll dinamicamente, para cargar un bpl, seria con LoadPackage : NULL; // si no existe devolvemos un NULL y no entraria en el siguiente bloque if ( li != NULL ) { typedef void ( __stdcall* fsFuncion )( TIBDatabase *punteroEjemplo ); //definimos el tipo fsFuncion el cual sera un puntero a una funcion con la misma estructura que la de la dll fsFuncion miPunteroFuncion = ( fsFuncion )GetProcAddress( li, "miFuncionDLL" ); //declaramos, buscamos "miFuncionDLL" y asignamos la funcion de la dll en el puntero "miPunteroFuncion" de tipo "fsFuncion" if ( miPunteroFuncion != NULL ) //si miPunteroFuncion apunta a una funcion real, la ejecuto, y le paso lo que nesesite, y en caso de que devuelva algo lo recibo miPunteroFuncion( punteroAMiBD ); FreeLibrary( li ); //en caso de que ya hayamos terminado con el formulario y hayamos liberado TODOS los punteros que hallamos iniciado en ese formulario, se libera la dll } } |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
ejecutables mas pequeños | sidneyb | Varios | 11 | 01-10-2008 15:46:48 |
como creo ejecutables para windows vista | yack99281588 | Varios | 2 | 20-09-2008 01:10:17 |
Qué componente del Qreport debo utilizar para lograr esto? | LizdR | Impresión | 3 | 21-06-2008 23:12:16 |
Icono mostrados muy pequeños | Coco_jac | OOP | 2 | 14-07-2005 03:58:51 |
Para los pequeños saltamontes | santana | Humor | 2 | 20-01-2004 23:41:02 |
|