Newsgroup: it.comp.lang.visual-basic
Titolo: DLL, queste sconosciute

Ciao, volevo fare una domanda cretina. Perchè devo incasinarmi la vita
mettondomi a scrivere un sacco di dll, quando, nel creare un nuovo progetto,
posso prendere tranquillamente i miei vecchi moduli (.bas) e collegarglieli
(si dice così?)?. Mi sfugge il vantaggio...
Starla.
PS: Cosa vuol dire 'OT'?

Dai BAS alle DLL il salto è notevole, in quanto dentro i moduli bas ci sono
funzioni pubbliche che tutta l'applicazione alloca e vede costantemente, con
tutti i rischi che questo comporta (confusione tra nomi di variabili,
funzioni ecc..) e poi sono monoistanza, nel senso che una variabile
dichiarata in un bas e inizializzata mantiene il suo contenuto fino ad un
nuovo utilizzo.
Le variabili invece, usate in una classe e istanziate più volte hanno
funzionalità più estese
Supponi di avere una variabile CODICE in una classe PIPPO, crei 3 istanze a
PIPPO
Set myPippo1 = New PIPPO
Set myPippo2 = New PIPPO
Set myPippo3  = New PIPPO
ed hai 3 copie di CODICE a disposizione. con un bas non lo puoi fare.
Il dubbio pratico potrebbe essere nell'utilità di fare DLL piuttosto che
tenere le classi come sorgente direttamente nell'applicazione, che a tutti
gli effetti di programmazione non fa differenza.
beh, la DLL di norma rende più chiaro e flessibile il codice. Tutto quello
che è definitivamente testato, funzionante, e generico, sta bene in una DLL,
piuttosto che portarsi dietro le copie di sorgenti nei vari programmi.
Ovviamente questo vale per progetti di dimensioni notevoli, non per piccoli
sorgenti
Poi, perché "tante" ?. Io credo che ogni programmatore doverebbe creare la
*sua* dll nel suo stile e nelle sue necessità e a mano a mano farla
crescere. perché 'tante' DLL?
Fabio

Wow, grazie per il chiarimento (tanto le dll non le so fare, quindi!
:=))))).
Comunque, dicevo "tante", nel senso, io credo bisognerà creare un dll per un
certo tipo di funzioni, una dll per un altro.. o sbaglio? Come i moduli,
creo un modulo per i dati, un modulo per il login al programma, un modulo
per la gestione delle finestre etc... no?
Non mi avete detto cosa vuol dire 'OT'! ;)
Ciao grazie ancora.
Starla.


 ha scritto
| Non mi avete detto cosa vuol dire 'OT'! ;)
Off Topic... cioe' non inerente all'argomento (che in questo NG e' VB)... :)

 ha scritto
| Dai BAS alle DLL il salto è notevole, in quanto dentro i moduli bas ci sono
[CUT]
| Poi, perché "tante" ?. Io credo che ogni programmatore doverebbe creare la
| *sua* dll nel suo stile e nelle sue necessità e a mano a mano farla
| crescere. perché 'tante' DLL?
Ottima spiegazione! Pero' chiedo a questo punto: come faccio a convertire i miei .BAS in una DLL? E
come posso utilizzare poi le funzioni della DLL (anche se suppongo si faccia con le "Declare")? So
come convertire una classe in una ActiveX DLL, ma non i .BAS... :(

Cazzarola, come sono tardo! Ci potevo arrivare da solo! Grazie ciao. Starla.
"Jabba The Hutt" <Jabba....@Alderaan.SW> ha scritto nel messaggio
news:Ch4S7.2983$o9.1...@news1.tin.it...


devi creare una nuova classe e aggiungere le tue funzioni
a questo punto nel proggy
dim myfuncs as newclass
myfuncs.SetBackGroundColor(vbYellow)
...
ciao
L2K

 ha scritto

Ecco, era proprio questo che avevo paura di dover arrivare a fare... sigh... :(

Sbagliato scusa.... ho controllato... se vuoi che le tue funzioni siano
esportate le aggiungi ad una classe e setti la proprieta Instancing della
classe su Global MultiUse a questo punto continui ad utilizzare le tue
funzioni.... un esempio lo trovi su 
vbaccelerator.com
 nella dll ssubtmr
ciao e scusa... era una novità anche per me e credo non molti lo sappiano
L2K


 ha scritto


il copia e incolla č il miglior metodo :)
copi dal bas e incolli nella classe, poi le strutturi in modo che abbiano un
senso piů orientato all'uso come oggetto

 per la gestione delle finestre etc... no?
no appunto, qui sta l'utilità della DLL. Tutti i bas li porti in una DLL, e
chessò, con una sola classe.
Nella classe implementi tutte le sub e le funzioni che richiamano altre
funzioni sparse nei vari bas
poi, una volta compilata la DLL, nella tua applicazione vedrai solo i metodi
che hai definito nella classe, e tutto il codice dei bas sarà invisibile.
Questo ti faciliterà il compito durante la programmazione
Poi sta a te, che implementi la dll, a dargli la struttura che ti è più
congeniale. insomma, te la fai su misura.
A forza di bas, funzioni e variabili, perdi il controllo.
poi, per capire come funzionano vanno fatte, e mano a mano che si capisce il
concetto, si arrivano a fare  cose impensabili
ah! una raccomandazione. Se usi o userai collezioni di oggetti cls al posto
di array le prestazioni sono alla grande inferiori. Gli array sono in
assoluto più performanti.
fabio

prova cosi
-Progetto nuovo DLL Progetto1
-crea una classe  pippo.cls
- creaci una sub clsMetodo
Sub clsMetodo
  Msgbox "Pippo"
End Sub
- poi fai Aggiungi Progetto, Nuovo, Tipo Exe Progetto2
- vai sui riferimenti e aggiungi Progetto1
- Metti un commandBotton sul Form
- Inserisci nel codice del CommandButton:
 Dim MyPippo as New Pippo
 Pippo.clsMetodo
-avvia il programma Progetto2 e premi il pulsante. ti verrà mostrato "Pippo"
che sta nella dll
Posto che nella sub cslMetodo ci metti richiami ad altre funzioni contenute
nei BAS (sempre della dll)
tutti i tuoi bas sono accessibili in questo modo senza cambiare una virgola.

 ha scritto
| prova cosi
[...]
Non ce n'e' bisogno! E' sufficiente modificare l'estensione dei .bas in .cls e poi impostare la
proprietà Instancing della classe a GlobalMultiUse... (a dir la verità forse ci sarà bisogno di un
copia incolla con una nuova classe, pero' l'idea e' sempre la stessa). In questo modo non devo
creare oggetti nuovi per poter utilizzare le funzioni della mia libreria... senza pensare che nel
codice in cui utilizzo le funzioni non devo modificare alcunche', non devo aggiungere
"istanzadiclasse." davanti ad ogni chiamata di funzione...
Ciao!

non è vero che non crei oggetti nuovi
è vb che crea un istanza globale
quindi la classe comunque occupa memoria... però è una cosa non importante.
Credo come te che l'utilita sia nel non dovere scrivere tutte le volte
"myclass."
ciao
L2K

 (si dice così?)?. Mi sfugge il vantaggio...
Aggiungo una cosa banale, ma allo stesso tempo essenziale, che mi sembra non
sia stata affrontata negli altri messaggi: manutenzione del codice.
Il giorno che decidi di modificare una funzione, nel tuo modulo o modulo di
classe coscenziosamente incluso nei tuoi 30 programmi devi ricompilare tutti
e 30 gli eseguibili se vuoi che la modifica abbia effetto globale!!
Viceversa puoi ricompilare solo la tua DLL e passare la serata con gli amici
invece che davanti a VB :-)
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

se è compatibilità primaria funziona tutto da dio... senza farsi aiutare e
compilando una sola volta
e quindi può andare al cinema tranquillo
LOL
L2K

 con la nuova DLL
Come ha gia' detto Lukino2K, questo non e' del tutto esatto...
se usi l'associazione tardiva non hai problemi di compatibilita', su usi
l'associazione anticipata e' sufficiente mantenere la compatibilita' binaria
della DLL; in questo caso esistono modifiche nelle interfacce del componente
che necessariamente interrompono la compatibilita', ma se le classi
pubbliche sono state "ponderate" un minimo all'inizio, tali modifiche non
sono frequenti...


Cribbio, hai ragione! Che scemo, potevo pensarci prima!
Grazie (inizierò a capire come si fanno queste dll!)
Starla.
"Luca Dormio" <lucaFaV...@tinFaVa.it> ha scritto nel messaggio
news:9vas1e$3v9$1...@fe2.cs.interbusiness.it...


 ha scritto
| non è vero che non crei oggetti nuovi
Ottima precisazione... sono ancora un po' profano dei meccanismi che governano le DLL...
| è vb che crea un istanza globale
| quindi la classe comunque occupa memoria...
| però è una cosa non importante.
Mica tanto... quanto spazio occupa in memoria un'istanza di una DLL da 1MB? E se poi c'ho tanti
programmi che utilizzano la stessa DLL, ognuno si crea la sua istanza, o viene utilizzata la stessa
creata dal primo che sia stato messo in esecuzione? Se vale la prima che ho scritto, capisci che la
dimensione ha la sua importanza...
A questa si potrebbe ovviare creando tante DLL, separando logicamente le funzioni, con la
controindicazione di dover utilizzare numerose e diverse DLL nei progs e di dover tenere traccia di
quali DLL siano state usate e quali no nei vari progetti...

 wrote in message
news:wN3S7.296307$sq5.14...@news.infostrada.it...

-- 
Posted from  [212.31.245.72] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 proprietà Instancing della classe a GlobalMultiUse...
be, si è ovvio, questo basta. ma sai che macello.. di norma ti ritrovi tutto
pubblico. L'ideale è, se fai una classe, dargli anche l'aspetto e un minimo
di struttura, che non è quella del bas

 ha scritto

Dipende dalla struttura che si e' dato al .bas! Se tu concepisci i moduli come un oggetto in cui
riporre le variabili globali, beh... di certo quelle variabili non staranno in un modulo
riutilizzabile!
Inoltre la mia intenzione non e' quella di scrivere una classe!
Se voglio scrivere una classe non utilizzo VB, ma Java o C++. E la progetto prima di implementarla.
Naturalmente con questo non dico che non scrivo classi in VB, ma sottolineo solo il mio disappunto
per la mancanza di meccanismi (se non per vie traverse e con trucchetti) quali l'ereditarietà che
fanno di VB6 un linguaggio _solo parzialmente_ object-oriented.
In più non sempre si ha la necessità di una classe. Per esempio: se vuoi sapere se un file esiste,
per come la vedi tu, dovrei scrivermi una classe con il metodo "FileExist(nomefile as string)",
istanziare esplicitamente un oggetto di quella classe ed invocare il suddetto metodo. Ma non e'
questa la programmazione ad oggetti!
La mia intenzione era semplicemente di poter distribuire, senza scrivere tonnellate di modifiche ai
progetti esistenti, le mie librerie personali sotto forma di compilato senza che, quando si presenta
la necessità di consegnare anche i sorgenti, queste diventino di proprietà di chi si prende il
progetto.
E con questo non intendo polemizzare sull'utilità o meno delle classi di VB, o della chiarezza di
lettura di un codice in cui ogni cosa stia al suo posto nella sua classe. Semplicemente certe
funzioni hanno poco senso in una classe...