Newsgroup: it.comp.lang.visual-basic
Titolo: Dimensioni exe

Ho un prg che negli anni è via via cresciuto, causa aggiunte e modifiche, e
adesso supera il megabyte.
Volendo farlo dimagrire dove  mi conviene intervenire per avere un risultato
maggiore?
Codice? Indicizzare a tappeto tutti i controlli?
Greg

maggiore?
E' difficile dirlo se non si sa l'eseguibile cosa faccia, come lo
faccia e con cosa lo faccia.
Se contiene immagini, un bel risparmio si ha salvandole tutte come
risorse e caricandole quindi a runtime. Se il file di risorse e'
grosso si puo' salvare a parte, fuori dall' eseguibile, in una dll.
Se e' compilato in codice nativo si puo' scegliere di ottimizzare per
le dimensioni (io lo faccio sempre), oppure si puo' decidere di
compilare in p-code (per molte attivita', come l'accesso a database,
le prestazioni non sono per niente penalizzate).
Se combini le due soluzioni qua sopra puo' "dimagrirlo" parecchio,
riducendolo anche a 3/400 KB al massimo.
-- 
ciao, hal

 ha scritto nel messaggio
news:snbp7vcengcokvf0b...@4ax.com...


Il prog è un gestionale, usa solo un'immagine, quella automatica dello
spash, un solo ocx "esterno" per il resto text, label, data, dbcombo, grid,
flex e button distribuiti in 19 forms.
Essendo il programma cresciuto nel tempo, al secondo datacontrol e button
che mettevo sul fol form ho sempre rifiutato di idicizzarlo, pensando che
per uno solo in piu non cambia nulla, poi son diventati 2,3,4,5.... adesso
mi rendo conto che con una matrice di controlli si risparmia in dimensioni e
in memoria... oltre a poterli gestire meglio in caso di cicli...
Un'altra cosa: c'è un modo per sapere le linee totali del codice senza
doverle cintare form a form?
Grazie
Greg

 doverle cintare form a form?
http://www.mztools.com/
, un must assoluto. Freeware :-)
Bye, G.

 in memoria... oltre a poterli gestire meglio in caso di cicli...
Per le dimensioni non so, per la memoria non cambia assolutamente niente
(almeno questo garantisce Microsoft con win32).
L'unico vantaggio è nella gestione degli eventi e nei cicli, ma sei sicuro
che questo ti serva per dei commandbutton?
P.S.: .NET non gestisce i controlli indicizzati, o meglio, non li gestisce a
design time.
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

e caricandole quindi a runtime
Ecco, diciamo che ho delle immagini in un file risorse, salvato in una
dll,con che codice richiamo una data immagine ?
Scusa hal1961 se ci riprovo.... ma perchè hai pensato ad un "trollaggio" ?
Grazie
--
Gulp ! Forse mi sono perso qualcosa !

 Scusa hal1961 se ci riprovo.... ma perchč hai pensato ad un "trollaggio" ?
Se la dll č una dll ActiveX (di quelle fatte con VB per intenderci) puoi
anche fare a meno del .res e mettere le tue immagini in picturebox o image
nascoste.
Ma poniamo che tu abbia il tuo file .res, č indifferente.
Ti fai una classe Immagini con un metodo Load(ID) As IPictureDisp e
restituisci il tutto con LoadResPicture()
Ciao.


 picturebox o image nascoste.
Infatti alla fine mi sono "rassegnato" a far così, perchè non conoscevo il
modo che mi hai indicato.
Diminuendo le dimensioni dell' EXE vi sono indubbi vantaggi nella
performance dell' applicazione, il problema che mi sto ponendo è questo: nel
momento in cui devo caricare immagini attraverso una Dll Active X sarà più
veloce un Exe grande con le immagini già incluse o continue chiamata ad una
Dll?
Sto pensando ad es. ad un form di menu' che contiene una immagine (logo) e
che essendo un menu', appunto, viene riaperto spesso da altri form.
Ciao
Grazie.


 Dll?
Indubbiamente la prima che hai detto. Non dimenticare inoltre che _in quel
momento_ la memoria occupata č la somma dell'EXE + la DLL, anzi, sicuramente
qualcosa in piů, quindi i vantaggi di un EXE piů piccolo (ma "parzialmente
sdoppiato" su una DLL) non sono certo dal punto di vista della memoria
occupata. Spero di non aver detto sciocchezze... a suo tempo mi ero posto lo
stesso dubbio...
Dove sono le mie (poche) immagini? Bellamente su file di disco e le carico
con LoadPicture...

 Dll?
Le DLL ActiveX sono in-process, quindi, almeno teoricamente è come se tu le
avessi incluse nel tuo exe.
Ovviamente se prima l'immagine era già caricata a design e ora la carichi a
runtime il processo potrebbe essere leggermente più lento, ma se è per
piccole immagini in piccole procedure (cioè non loop time-critical :)) non
vedo alcun problema.
Ciao
