Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Otros entornos y lenguajes > C++ Builder
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 19-02-2015
michal michal is offline
Miembro
 
Registrado: feb 2015
Posts: 27
Poder: 0
michal Va por buen camino
ayuda para lograr ejecutables pequeños

Hola a todos

Necesito me den criterios sobre mi proyecto.

Estoy haciendo una aplicación con muchos formularios, como es natural, el ejecutable final está aumentando de tamaño, todavía no voy ni por la mitad del proyecto y mi .exe pesa 40 Mb.

Cómo puedo solucionar eso??

Pensé en crear dlls con varios formularios afines, y me apareció un problema mayor: Esos formularios contenidos en las dll tienen componentes botones, TEdits, TComboBoxes, etc. No logro asociarle, por ejemplo, una función "contenida en la misma dll" a un boton, me da error.

No sé que hacer, tal vez con las dll no sea la solución.

Gracias
Responder Con Cita
  #2  
Antiguo 19-02-2015
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

No creo que lo que ocupen 40 MB sean los formularios como tales. Ni siquiera los componentes que haya en ellos. Se me ocurre que tal vez estés usando imágenes y que estas puedan ser más o menos optimizadas para que ocupen menos tamaño. Asegúrate también de que no estamos hablando del tamaño del ejecutable incluyendo información para su depuración. Si esto fuese así piensa que existe la opción para no incluir dicha información y así reducir el tamaño del programa ejecutable. Iba a añadir que tampoco debes preocuparte demasiado por el tamaño, puesto que si el programa ha de ocupar eso, habrá de hacerlo, pero, no significa que tenga que funcionar mal. Sin embargo, me parecen muchos 40 MB.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #3  
Antiguo 19-02-2015
michal michal is offline
Miembro
 
Registrado: feb 2015
Posts: 27
Poder: 0
michal Va por buen camino
Gracias dec, ya le habia eliminado la info sobre depuración. Estimo que mi proyecto, que en realidad es un sistema de facturación con conexión a base de datos sql, comunicación tcp/ip ,impresión y etc. ronda por los 90 y pico de formularios, cargaditos de componentes, y tambien con imagenes de fondo, menús, bueno tu sabes...
Y no está pensado para PCs muy modernas. Yo vivo en Cuba. Y Algunas PCs son Pentium 3 con 128 Mb de RAM y micros de 500 MHz. Por eso estoy tratando de optimizar el proyecto al máximo.

Qué me dices de la opción de incluir los formularios en dll que iré cargando y descargando a medida que necesite esos forms???
Responder Con Cita
  #4  
Antiguo 19-02-2015
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

La opción que propones no parece algo sencillo, pero, mucho menos si partes de la base de tener que lidiar con 90 formularios que ya están trabajando de otra forma, no sé si me explico. Creo que debes más bien mirar el asunto de las imágenes. Es posible que estés usando Bitmaps pudiendo usar algo más liviano como JPG, por ejemplo. De todas formas no sé hasta qué punto un ordenador tiene más problemas con leer un Bitmap grande que no un JPG algo más pequeño de tamaño. Creo que el rendimiento de tu aplicación no debería verse comprometido por tener 90 formularios (aunque me parecen muchísimos) pero mira a ver si es que estás creándolos todos a la vez, procurando crearlos cuando sean necesarios y destruirlos cuando no lo sean.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #5  
Antiguo 19-02-2015
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Cita:
Empezado por dec Ver Mensaje
... estás creándolos todos a la vez, procurando crearlos cuando sean necesarios y destruirlos cuando no lo sean.
Responder Con Cita
  #6  
Antiguo 19-02-2015
Avatar de nlsgarcia
[nlsgarcia] nlsgarcia is offline
Miembro Premium
 
Registrado: feb 2007
Ubicación: Caracas, Venezuela
Posts: 2.206
Poder: 21
nlsgarcia Tiene un aura espectacularnlsgarcia Tiene un aura espectacular
michal,

Cita:
Empezado por michal
...Estoy haciendo una aplicación con muchos formularios...todavía no voy ni por la mitad del proyecto y mi .exe pesa 40 Mb...vivo en Cuba...Algunas PCs son Pentium 3 con 128 Mb de RAM y micros de 500 MHz...estoy tratando de optimizar el proyecto al máximo...


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:
Espero sea útil

Nelson.
Responder Con Cita
  #7  
Antiguo 20-02-2015
michal michal is offline
Miembro
 
Registrado: feb 2015
Posts: 27
Poder: 0
michal Va por buen camino
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.
Responder Con Cita
  #8  
Antiguo 20-02-2015
Avatar de Ñuño Martínez
Ñuño Martínez Ñuño Martínez is offline
Moderador
 
Registrado: jul 2006
Ubicación: Ciudad Catedral, Españistán
Posts: 6.000
Poder: 25
Ñuño Martínez Tiene un aura espectacularÑuño Martínez Tiene un aura espectacular
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.
__________________
Proyectos actuales --> Allegro 5 Pascal ¡y Delphi!|MinGRo Game Engine
Responder Con Cita
  #9  
Antiguo 20-02-2015
Avatar de nlsgarcia
[nlsgarcia] nlsgarcia is offline
Miembro Premium
 
Registrado: feb 2007
Ubicación: Caracas, Venezuela
Posts: 2.206
Poder: 21
nlsgarcia Tiene un aura espectacularnlsgarcia Tiene un aura espectacular
michal,

Cita:
Empezado por michal
...No uso Delphi sino C++Builder 2009 aunque también tengo la versión 6....


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.
Responder Con Cita
  #10  
Antiguo 20-02-2015
engranaje engranaje is offline
Miembro
 
Registrado: may 2011
Posts: 163
Poder: 13
engranaje Va por buen camino
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.
Responder Con Cita
  #11  
Antiguo 20-02-2015
Avatar de aguml
aguml aguml is offline
Miembro
 
Registrado: may 2013
Posts: 885
Poder: 11
aguml Va por buen camino
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.
Responder Con Cita
  #12  
Antiguo 25-02-2015
_cero_ _cero_ is offline
Miembro
 
Registrado: abr 2007
Posts: 147
Poder: 17
_cero_ Va por buen camino
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 );
Puedes buscar más información de que significa cada palabra, pero a grandes rasgos, estas declarando una función estándar que las otras aplicaciones podrán llamar, estas funciones son tal cual las funciones normales, es decir pueden devolver cualquier valor que requieras (otra vez a costa de la estandarización), o recibir cualquier cosa que requieras.

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
	}
}
Pd. Esto debería compilar sin problemas, cualquier cosa comenta.
Responder Con Cita
  #13  
Antiguo 25-02-2015
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Cita:
Empezado por _cero_ Ver Mensaje
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.
Creo que alguien sugirió antes, y preguntó, si crea todos los forms al comienzo o si los va creando según se van necesitando. Me parece que no he visto la respuesta a esa pregunta.
Alguna vez he comentado en algún mensaje que el último programa en el que estuve trabajando tenía cerca de mil formularios (1000) y no tenía ningún problema para funcionar en cualquier pc normal y corriente.
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
ejecutables mas pequeños sidneyb Varios 11 01-10-2008 16:46:48
como creo ejecutables para windows vista yack99281588 Varios 2 20-09-2008 02:10:17
Qué componente del Qreport debo utilizar para lograr esto? LizdR Impresión 3 22-06-2008 00:12:16
Icono mostrados muy pequeños Coco_jac OOP 2 14-07-2005 04:58:51
Para los pequeños saltamontes santana Humor 2 21-01-2004 00:41:02


La franja horaria es GMT +2. Ahora son las 14:05:55.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi