Newsgroup: it.comp.lang.visual-basic
Titolo: Consiglio

Salve,
volevo fare un programma che, per quanto sia limitata
la programmazione ad oggetti di vb6, mi permettesse
di utilizzare delle dll esterne come degli oggetti.
Spiego meglio l'arcano.
Immaginiano una rubrica di telefono. La rubrica avrà
una singola entità, il numero che sarà corredato da
nominativo, indirizzo, e-mail ecc. ecc.
Ora mi piacerebbe fare un'applicazione a moduli che
dato l'exe di vb6 che contiene solo le form e la logica
di attivazione-disattivazione dei campi, si appoggi
su una dll esterna per ogni modulo del programma che esponga
metodi e proprietà relative al numero in questione.
Avrò quindi un metodo ricerca, uno inserisci, uno cancella
uno popolamaschera, uno aggiorna e diverse proprietà
(ma qua non sono sicuro) che mi permettono di interrogare
il singolo valore di ogni campo.
Il dubbio è proprio su questo punto. Secondo voi fare una
proprietà in cui passo mezzo array tutti i campi per riferimento
della mia form alla dll esterna, e poi da dentro la dll quando
chiamo popolamaschera riempo le proprietà text o caption
che vogliano essere di questo array, può funzionare?
Teoricamente si. Questo mi darebbe un bel vantaggio nel
programmare perchè in caso di aggiornamenti sul formato
dei dati o alle query, non vado a redistribuire un exe grande
chissà quanto, ma solo una o più dll che ho toccato, e per
giunta, passando i campi per riferimento, non sono nemmeno
obbligato a preoccuparmi di eventuali aggiunte o cambiamenti
di nome dei controlli nel mio form, perchè basta solo cambiare
nome che ho risolto.
Voi che ne pensate?
Ciao
Angelo


La scelta di dll esterne, gestite nella forma corretta, corrisponde secondo
me allo stile migliore di programmare, ma se il tuo obbiettivo sta nella
facilità di distribuzione considera che ogni volta che tocchi una dll devi
ricompliare anche l'exe, poiché cambiano i riferimenti e 'non si riconoscono
più'
Le dll di cui stiamo parlando sono ActiveX, che l'EXE lega a se stesso in
fase di compilazione e non viceversa. Se invece si trattasse di DLL standard
di windows il problema non si presenterebbe in quanto vengono caricate al
momento della richiesta di una sua API.
Ad ogni modo una corretta pianificazione di DLL esterne offre notevoli
vantaggi.
Fabio

 più'
Davvero?
Sei sicuro?
Ma allora la compatibilità a cosa serve?

 momento della richiesta di una sua API.
Non è così. Qualsiasi dll viene linkata dinamicamente (da qui appunto il
nome) agli exe al momento dell'esecuzione. La differenza fondamentale fra
dll 'vecchio stile' e le nuove dll di win32 sta nel fatto che queste ultime
supportano un protocollo più rigoroso di comunicazione con le applicazioni
(COM) che consente di stabilire con esse una forma di dialogo un pochino più
sofisticata della semplice conversione del nome di una funzione in un
indirizzo di memoria (come accadeva nelle vecchie dll). Gli eseguibili non
incorporano parti del codice delle dll, ma riferimenti ad esse. Quindi
quando si ricompila una dll non è necessario ricompilare gli eseguibili -
sarebbe altrimenti un massacro tutte le volte che MS produce un service
pack.
Per quanto riguarda il quesito iniziale, posto che le dll vengano mantenute
in compatibilità binaria, c'è da chiedersi se il gioco valga la candela. Per
realizzare in vb6 un exe che occupi, diciamo 1MB (diciamo 300KB zippati),
bisogna darsi daffare, per arrivare sui 2MB bisogna veramente sudare le
fatidiche sette camicie (altrimenti vuol dire che si è sbagliato qualcosa,
tipo aver inserito bitmap nel progetto o altri file nelle risorse). La
scelta di usare le dll non va fatta (solo) pensando alla distribuzione: non
credo che seriamente oggi 500KB siano un problema su nessun tipo di
trasporto e d'altra parte, manutenere e installare una dll è certamente un
pochino più faticoso che lavorare con un solo exe. La scelta delle dll
normalmente viene fatta per rendere il codice centrale indipendente da
particolari strumenti (
p.es
. chiamo una funzione che mi apre il db senza
sapere come lo farà e caricando la dll che trovo in un file di
configurazione) e per rendere lo stesso codice fruibile da parte di
applicazioni diverse (o istanze diverse della stessa applicazione). D'altra
parte, se quello che ti interessa è anche la programmazione a oggetti, non
vedo perché ricorrere necessariamente a oggetti esterni: potresti
tranquillamente usare classi interne al tuo progetto exe - e magari
organizzare il progetto in vista di una possibile scissione in più
componenti. Insomma, potresti iniziare organizzando il progetto come se
lavorassi con librerie esterne sfruttando l'oop e incapsulando il codice in
classi del progetto. Se poi dovesse rendersi necessaria la seprazione in più
moduli, allora l'operazione sarebbe semplificata dalla struttura del
programma.
Credo che poi si debba considerare l'aspetto pratico della fase iniziale del
progetto. E' chiaro che anche per te sarà più facile realizzare e fare il
debug di un progetto unico. Una volta superata la fase di alpha-test,
potresti pensare a scindere il progetto in più componenti - anche se questo,
ovviamente, significa far regredire di nuovo il progetto ad alpha-test.
--
rumplestilskin

> Ma allora la compatibilità a cosa serve?
Proprio a permetterti di redistribuire le dll senza ricompilare
l'exe. L'importante è che non vai a toccare la struttura
della dll esterna altrimenti - fatto salvo che in fase di ricompilazione
vb ti avverte - il progetto esistente non funzionerebbe più.
Diversamente puoi aggiungere quello che vuoi in
termini di funzioni private, nuove public o modificare il
codice interno delle routine esistenti.
Ciao
Andrea

La scelta non è poi male. Diciamo che come ha notato
rumplestilskin è assai più elaborata che non gestire tutto
in un unico progetto.
Tuttavia avere molteplici dll significa effettivamente
ridistribuire solamente piccole porzioni di programma
e non tuto l'eseguibile. Significa non sapere cosa fa
una dll ... cioè nel caso tu lavori in un gruppo di lavoro
uno fa le form, uno le dll di interfacciamento al db ...
e tu che usi la dll non devi preoccuparti di sapere come
si connette il db o come recuper dati, ma solo di prenderli
e usarli. Se lavori da solo ... beh la scelta potrebbe essere
interessante quando aprirai una società :)
Personalmente sto lavorando adesso su di un progetto
che ha dentro una 10 di form e altrettanti moduli e sono
arrivato velocemente al MB ... diciamo che è quasi
finito il progetto ... però se anche io avessi scisso il
codice in dll esterne avrei avuto un exe più piccolo, più
veloce da caricare e più facile da redistribuire.
Per la seconda parte del quesito, quella dove passi
tutti i campi in un array, ti consiglerei anche di dare un
occhio alla possibilità di fare delle dll data-aware ... cioè
fornitrici di dati, che mediante la proprietà datasource
di ogni controllo linki alla tua dll e utilizzi senza davvero
nemmeno preoccuparti di fare la classica cosa
text1.text = rs("miocampo")
ciao
Andrea

 tipo aver inserito bitmap nel progetto o altri file nelle risorse).
Bavvè, non l'ho mai negato e lo ribadisco: Io non ho una sola bitmap, nè
alcun file RES, ma perchè i miei EXE (solo, tanto per esemplificare, quelli
del modulo magazzino) occupano circa 20Mb su 4 EXE?
Dici che ho sbagliato qualcosa, possibilissimo, ma io tutto quel codice che
_deve_ esserci dove lo sbatto?

Ah, e ho una DLL esterna, comune a tutti gli EXE, di 1.3 Mb.

ops, scusate. Non uso mai compatibilità binaria perché mi fa più casino che
altro
La mia abitudine è di ricompilare tutto, più che altro per prevenire
sorprese.
ri-ri-chiedo scusa!
Fabio

 _deve_ esserci dove lo sbatto?
5MB per exe! Ma il caricamento lo fai fare da un apposito batch notturno?-)
(Il piů grande prg che io abbia mai compilato occupa un paio di mb e vorrei
avere il tempo per smontarlo e ridurlo a meno della metŕ.) Comunque sia, io
non dico che il nostro amico non abbia ragione (non a caso i miei exe sono
quasi tutti al di sotto del mb perché li propino assieme a svariate decine
di mb di dll, a parte quelle di MS). Il fatto č che, dalle domande, mi ero
fatto l'idea che non fosse un programmatore con il pelo sullo stomaco e
quindi non avesse intenzione doi partire subito con progetti da un milione
di righe di codice (a me almeno per arrivare a questi dimensionamenti mi
tocca mettere insieme oltre il milione di righe), da qui ipotizzavo una
soluzione almeno temporaneamente diversa. Se il quesito lo avessi posto tu,
me ne sarei guardato!
--
rumplestilskin

Se il quesito lo avessi posto tu, me ne sarei guardato!
E perchè mai? In effetti io non sono intervenuto per rispondere al quesito
iniziale (e, anche se in ritardo, me ne scuso), ma, collegandomi a una tua
affermazione che mi ha interessato, ne ho fatto uno mio: Come cacchio faccio
a ridurre i programmi?
Se hai idee, guardati bene dal _non_ dirle. ;-)
Quindi forza, sempre per favore, neh? Grazie.

 Quindi forza, sempre per favore, neh? Grazie.
Non ci siamo mica capiti: ti pare che io abbia un metodo per ridurre il
codice - a parte le raccomandazioni da maestrina su portare il codice in
funzioni più generiche e poi portare i raggruppamenti di funzioni in
librerie? Non mi pare di averlo detto. Ho solo detto che non mi pareva
possibile che il nostro amico potesse avere problemi del genere e nel
contempo porci domande come quelle. Se avesse avuto un exe da 5MB (tolte le
solite res) non credo che avrebbe postato tale richiesta, perché
l'esperienza maturata nel realizzare qualche centomila righe avrebbe reso la
domanda superflua.
Resta comunque il fatto che i miei exe non superano normalmente 1MB.
Dipenderà da cosa c'è dentro (codice leggero? frivolo? mischiato a fecola?).
Però io uso normalmente parecchie dll, molte delle quali stazzano sempre sul
MB l'una. Questo sia di monito per Angelo: che pure le dll poi crescono e ti
presentano lo stesso problema!
--
rumplestilskin
(PS: vedo ora che uno dei setup installa qualcosa come 104 fra exe, dll e
ocx!!! Mesi fa erano meno, ne sono quasi certo: che si riproducano stando lì
la notte?)