Newsgroup: it.comp.lang.visual-basic
Titolo: Ma perchè usare DLL e non semplici Funzioni?

Probabilmente sto facendo una domanda cretina ma io finchè non capisco bene
le cose sono tignoso
Tutti i grandi applicativi una volta installati hanne delle dll personalli.
In genere le librerie memorizzano routine e quando un progetto viene
eseguito, può chiamare ruotine contenute in librerie. Dai manuali leggo che
ciò è particolarmente utile per routine utilizzate da molti progetti quindi
se si devono fare delle modifiche invece che modificare tutti i progetti si
modifica la dll. Giusto?
Finche si scrivono programmi piccoli forse le dll non sono importanti ma se
si pensa di codificare progetti dove col tempo aumentino di funzione forse
sarebbe il caso di usarle per evitare,, magari, di scrivere codice già
scritto.
[quest'ultima frase è da analizzare]
1^Domanda
Io non capisco se per il mio bene è meglio che lasci perdere le DLL o se
magari interessarsi a conoscerle meglio.
2^Domanda
Quando mi devo sentire obbligato a crearmi delle DLL personali?
3^Domanda
Voi quando vi siete accorti che le DLL vi hanno aiutato? (gradire un esempio
pratico)

 modificare tutti i progetti si modifica la dll. Giusto?
Beh, sarebbe la stessa cosa fare dell S/F in un modulo BAS e modificare
comunque una volta sola e ricompilare.
Io non credo che una DLL abbia molti vantaggi, specialmente se in
compatibilità binaria. Eppure ne ho una.
Non ha vantaggi in termini di compilazione perchè ogni modifica della stessa
presume la ricompilazione di tutti i progetti che vi fanno riferimento per
rigarantire la compatibilità.
Non ha vantaggio in termini di occupazione in memoria perchè comunque
EXE+DLL occupa (forse più) di quanto occupa EXE (più grosso su disco, ma da
solo) comprensivo delle varie S/F che stanno nella DLL.
Non ha vantaggio in termini di velocità di esecuzione perchè chiamare un S/F
nello stesso EXE è più veloce che farlo in una DLL esterna.
Non ha vantaggio per il passaggio dei tipi (un Type / UDT non può essere
passato)
...
Che vantaggi ha? Io sinceramente non lo so... Forse quello di rendere
disponibile la DLL ad altri senza fornirne necessariamente il sorgente, come
avviene per un OCX... Attendo anch'io notizie.

 Quando mi devo sentire obbligato a crearmi delle DLL personali?
1) In tutti i casi in cui 2 o più programmi devono condividere dei dati.
2) In tutti i casi in cui hai del codice che pensi di poter riutilizzare
3) ...anche in tutti gli altri casi! :-)
    Ciao
        Allanon
-- 
- SPAMKILLER
 lasciate il NOSPAM nell'indirizzo: 
itlangv...@michele.sytes.net
 e lasciate la parola SPAMKILLER nel corpo dell'email

 pratico)
allora, mi unisco a questo 3ed, non ho risposte precise, solo qualche
riflessione.
dunque, io trovo comodo usare dll per suddividere logicamente le funzioni di
un programma. Ti faccio un esempio pratico, ok?
un mio applicativo è composto da un EXE e da diverse DLL:
- WWStampa.dll
- WWBackup.dll
- WWContratto.dll
- WWUpdate.dll
e diverse altre. Come si deduce dal nome, ogni dll ha uno scopo ben preciso.
WWStampa.dll è bella grossa, contiene i file di report, tutto il codice per
stampare o per esportare la stampa in altri formati e così via. Se trovo un
bug, correggo, ricompilo e al cliente rimando WWStampa.dll, invece di un
unico EXE che magari sarebbe di 6-7 Mb, non so se rendo l'idea. Questo è
molto comodo anche in virtù del fatto che adesso sto implementando un,
chiamiamolo così, LiveUpdate del mio applicativo, cioè un aggiornamento da
remoto via Web. Ogni file può essere aggiornato indipendentemente dagli
altri.
Una cosa che trovo scomoda delle dll di vb è che sono costretto ad
istanziarle, non posso dichiararle come statiche come credo si possa fare in
.net. Cioè devo sempre fare la Dim, poi la Set = New xxxx e così via.
Concludo velocemente dicendo che se avessi un file bas pieno di sub/function
grande 50Kb e questo file bas viene usato da 10 progetti diversi, ciascuno
di questi progetti ha le funzioni duplicate al suo interno. Una minima
correzione ad una sub in questo file bas costringe a ricompilare
tutto.......
questo è quello che mi viene in mente a caldo, aspettiamo altre
impressioni.....
good coding!!!
-- 
Alletun
"Io lo so che accadrà. La voce sussurra nei miei pensieri di Jair, Rone,
Allanon e soprattutto nelle Mortombre.
Sussurra segreti che mi sono tenuti nascosti, nella grigia oppressione
di questo giorno e nell'oscurità caliginosa di quello che mi aspetta.
Saremo distrutti. Tutti."
Brin Ohmsford - La Canzone di Shannara - T. Brooks

Dunque.
Io credo che IN VB, non abbia molto senso creare delle DLL "vere".
Il vantaggio principale delle DLL è semplicemente uno: la DLL viene
caricata in memoria solo una volta, poi viene "rimappata" all'interno
degli altri eseguibili, ma in memoria c'è una sola copia condivisa.
Questo rende possibile diverse cose, tra cui risparmiare memoria se piu'
programmi fanno uso della stessa DLL.
Esempio pratico:
Supponiamo di avere una suite di programmi che ha:
1) Schermata di login,
2) Schermata di logout,
3) Lettura di un file di opzioni proprietario,
4) Schermata di about,
5) ecc
Se mettiamo tutte queste cose in una DLL "vera", non c'è
bisogno di ricompilare tutto A MENO CHE non si cambi l'interfaccia
della DLL stessa( motivo per cui in M$ quando devono cambiare un tipo, in
realtà la DLL resta con la stessa "firma" e poi usano un campo Size interno
per
verificare che versione della funzione è ).
Le DLL VB sono nate per gli OCX ed accrocchi simili, quindi naturalmente
hanno
meno senso... d'altro canto, considerate che le API stanno in DLL,
v'immaginate a
riscrivere il supporto per i Device Context di Windows ad ogni programma?
Tutto questo, ovviamente, imho.
Ciao,
Andrea

 comunque una volta sola e ricompilare.
Secondo me dipende dall'organizzazione mentale che ognuno di noi ha, non
esiste un principio generale, ognuno deve scrivere il codice come si sente
di scrivere il codice.
Però un esempio, seppur piccolo e marginale su qualche convenienza spicciola
che io ho riscontrato lavorando con DLL (nel mio piccolo, qui tutti sanno
che non sono nè un guru di Vb ne il titolare di alcuna software house nè
tantomeno un programmatore di "professione", diciamo che nella mia
professione programmo anche.... Insomma penso che, per il momento almeno,
mai e poi mai mi capiterà di lavorare in Team o su grandi progetti, quindi i
benefici reali che posso raccogliere dall'utilizzo delle DLL rimangono
comunque piccole cose, che però schifo non fanno).
In un modulo base una form non la metti, quindi non vedo come tu possa
facilmente crearne di già pronte da riutilizzare, è possibile, si fà lo
stesso, a 'sto mondo si fa tutto, ma secondo me è più brigoso, almeno per
me.... ripeto, ognuno ha i suoi schemi mentali.
I riferimenti a eventuali componenti esterni, anche ADO o DAO non sono così
semplici.
Se hai 10 riferimenti che ti servono, ogni volta che la importi devi
reimpostare gli adeguati riferimenti nel progetto exe padre, questi problemi
con una dll non li hai, perchè come la incorpori si porta dietro a cascata
tutti i riferimenti.
Queste potranno sembrare sciocchezze, ma nel mio piccolo le apprezzo.
-- 
Le persone non sono il proprio comportamento: devi sempre andare oltre,
essere flessibile, capire il punto di vista degli altri, interpretarne i
comportamenti ed intuirne le esigenze.
Per rispondere in privato elimina
dall'indirizzo "togliquesto"
MasterDavidex
David Ruscelli

 essere passato)
Hai il vantaggio che il createobject ha due parametri, il secondo
è il nome del server che ospiterà l'esecuzione del componente COM.
Hai il vantaggio di poter chiamare l'oggetto da linguaggi scripting.
Insomma i vantaggi sono tanti.
-- 
Salute e Saluti a Tutti.
-- 
Gabriele Del Giovine [Microsoft MVP] Windows Server
- Le informazioni fornite in questo messaggio sono fornite
  senza vincolo di garanzia e senza responsabilità alcuna.

 Insomma i vantaggi sono tanti.
Prego?

 Prego?
se a te non servono, non vuol dire che non ci siano vantaggi, significa
semplicemente che tu non te ne fai nulla........


 pratico)
Beh un esempio l'ho appena fatto prima.
Un'altro caso e' quando fai due o piu' programmi diversi ma che hanno
bisogno entrambi delle stesse funzionalita'.
Ad esempio nel caso di quella dll per le conversioni audio, la uso sia per
un programma piu' grosso (7 MB di installazione) sia come corredo per una
piccola utilty in C++ per convertire file mp3 in wav. (700kB in totale)
Quando devo fare modifiche al codice della conversione wav, modifico solo la
dll e distribuisco quella come aggiornamento invece di costringere a
reinstallare una nuova versione dell'intero programma.
ciao
Paolo B.

 verificare che versione della funzione è ).
Questo è vero (e soprattuto, aggiungo io) anche per gli oggetti COM (le
Actvex DLL...)


 (le Actvex DLL...)
LOL
M$ cambia le interfacce ed i contratti di COM come cambia pantaloni al
mattino, dai per favore!!!!
Basti pensare alle meravigliose interfacce di Office!
Ciao,
Andrea

Ragazzi,
Voi state parlando di DLL SchifezziX, qui invece si parla di DLL "VE-RE".
Vuol dire che le DLL SchifezziX non sono vere? Quasi :-)
Cioè ovviamente sono vere, ma sono un discorso tanto a parte da poter dire
quasi senza tema di essere smentito che una DLL SchifezziX NON E' una DLL.
Almeno, non è una DLL come la si intende solitamente, proprio perché è piena
di
schifezze :-)
Ciao,
Andrea

 driver).
LOL TI PREGO!
Fammela vedere una DLL "vera" non SchifezziX che in VB crea un
hook al mouse. Voglio proprio vedere come fai IN VB.
Ciao,
Andrea

 Voi state parlando di DLL SchifezziX, qui invece si parla di DLL "VE-RE".
Quelle schifezze sono invece molto utili.
Saluti.

 hook al mouse. Voglio proprio vedere come fai IN VB.
Usando le API e VisualDLL?
Hai una ActivexDLL mascherata da DLL "vera".
Cosi te la chiami da Visual C
Saluti.

 Basti pensare alle meravigliose interfacce di Office!
Infatti si chiamano in maniera diversa a seconda delle versioni di Office.
Io ho delle Activex DLL che hanno sempre lo stesso GUID ma che nel tempo
hanno
aggiunto nuove interfaccie. Ed i vecchi programmi non sono stati
ricompilati.
PS. Si può costruire un wrapper "DLL vero" alle librerie Activex DLL.
Saluti.

 ha scritto nel messaggio
news:buo2oq$p22$1...@fata.cs.interbusiness.it...

Ho detto di farlo con una dll scritta in VB?
Le dll in vb hanno solo la struttura delle dll ma hanno quasi tutte le
limitazioni dei programmi vb, per cui non possono essere usate per certi
hook.
Davo per scontato che mi riferivo a dll create in altri linguaggi,
principalmente il C++.
Fra l'altro rileggendo meglio la tua frase "Fammela vedere una dll vera" ...
sembra che tu dubiti che si possa creare un hook anche con una dll scritta
in c++.
Non comprendo proprio il senso di questa obiezione, per quale ragione una
dll in c++ non dovrebbe essere in grado di gestire un hook del mouse?
Solo perche' originariamente la funzione che crea l'hook e' stata chiamata
da un programma VB?
Mi pare una teoria alquanto bizzarra. :-)
ciao
Paolo B.

 Saluti.
Ciao,
Andrea

 deve necessariamente essere un ossimoro?
Perchè non vuole mollare l'osso. Perchè in M$ sono dei mercanti e, ma solo
in subordine, dei forti bevitori.

 Paolo B.
Ciao,
Andrea

 deve necessariamente essere un ossimoro?
Che significa interoperabilità tra le piattaforme? Piattaforme
di sistema operativo? Linguaggi di porgrammazione?
Protocolli di comunicazione? La tua affermazione/richiesta
non ha senso. Specifica meglio.
Saluti.

Gabriè,
Mi devi fare un piacere: non ti nascondere dietro un dito.
Tanto ti vedo lo stesso :-)
Dunque, partiamo da questo:
Gli ActiveX sono stati creati perché - sostanzialmente - serviva un modo per
condividere pezzi di codice complessi che non si potevano condividere via
DLL...
quindi, indovina un pò, si decise di usare le... DLL!
TSK!
Vorrei altresì far notare questa frase, emblematica imho:
"Activex è una implementazione di un concetto derivato dalla programmazione
ad oggetti/componenti. Era un valido pradigma per soluzioni non internet."
Verissima frase, peccato che:
1) ActiveX sia "esploso" con Internet
2) M$ abbia basato tutto ciò che era Internet proprio su ACTIVEX
3) Se ora ci ritroviamo zeppi di dialer dobbiamo ringraziare ActiveX
4) ActiveX è una PESSIMA implementazione del concetto di componente,
poiché non si può ereditare e
5) VB implementa gli ActiveX in un modo ancora peggiore di tutti gli altri.
Quand'è che in M$ avranno l'umiltà di dire "Ok, questo è meglio di quello
che
abbiamo fatto noi, usiamo questo", utilizzando e magari perché no,
migliorando
quello che c'è e che funziona BENISSIMO?
Hai presente le form XML di dotNET?
Bene, due concetti in uno: DFM di Delphi e XUL di Mozilla.
Ora, mi sta bene che adoperino questi concetti, ma che me li
facciano passare per nuovi mi sta MOLTO meno bene.
Quanto alla mia domanda su M$ ed interoperabilità, a parte SOAP, M$ non
interopera con NIENTE che non sia suo e manco sempre <g>, solo qualche
anima pia s'è smazzata perché M$ interoperasse. Sistemi operativi,
piattaforme,
dinne uno qualunque. Ed anche su SOAP, M$ ora è uscita dal consorzio,
quindi...
eheheheheh
Che vuoi che ti dica? Che è tutto bello? E' tutto bello!
Ma te lo posso solo dire, non pensare... <g>
Ciao,
Andrea

 facciano passare per nuovi mi sta MOLTO meno bene.
Che ti devo dire.  Non conosco DFM e XUL. Mi informerò.
Saluti.

 Saluti.

 quanto probabilmente tu stesso avresti voluto :-)
Dimostralo :-)
Saluti.

 Saluti.
Ciao :-)
Andrea

 Basta così, non sparo sulla croce rossa io ;-)
VB Implementa Activex nel miglior modo possibile per il programmatore VB.
Saluti.

 Saluti.
Andrea

 sotto WINDOWS :-)
Sei ottimista, io non lo sono. Quindi dico tutti i produttori.
Lotus ad esempio ci ha messo 6 versioni per far capire
al server SMTP di Notes come gestire i headers encoded usando i set di
carateri ISO. IBM ancora non lo capisce per il server SMTP dell'iSeries :-)
Saluti.

 Saluti.
Ciao,
Andrea

 dell'iSeries :-)
Non li conosco, ma in questi casi (2 vs 1) è lecito ipotizzare che il
demente sia chi ha concepito che gli "headers encoded", non chi cerca di
interpretarli... Non è la mamma? Demente lo stesso.

 essere lo stesso gruppo che ha fatto il Winsock, o no?
No. Sono due universi separati.
Saluti.

 Saluti.
Ciao,
Andrea

 ha scritto nel
messaggio news:buopt8$4ih$1...@newsreader2.mclink.it...


 ina...
La tua "domandina ina ina" è una delle classiche
"scatena-flame-di-portata-storica" :-)
Il fatto che un flame vero e proprio non ci sia stato, è dovuto
essenzialmente al
fatto che Gabriele ed io abbiamo diversi NG in comune e quindi ci "sappiamo"
:-)
Ciao,
Andrea