Newsgroup: it.comp.lang.visual-basic
Titolo: Specifiche per software modulare

Ciao a tutti,
sapete dove posso trovare, se esistono, specifiche per lo sviluppo di
software modulare (o a moduli)?
Devo sviluppare un software gestionale complesso e vorrei sapere come
renderlo modulare.
Grazie a tutti.
Francesco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Personalmente ho creato un progetto principale (.exe) e tante DLL quanti
sono i moduli dell'applicazione.
Nel progetto principale c'č una funzione che controlla quali DLL sono state
installate sulla macchina e, all'apertura del programma, istanzia i vari
moduli richiamando anche una procedura presente in ognuna delle dll che crea
automaticamente la/le voci di menů necessarie sulla finestra principale del
programma.
In questo modo č possibile aggiungere o togliere moduli semplicemente
registrando o deregistrando le varie dll.
Spero ti possa essere utile
ciao

mi intrometto anch'io.....
io ho un prj organizzato come il tuo......solo che.....
come fai a capire quando una DLL è stata installata oppure no?
provi ad istanziare l'oggetto ed eventualmente trappi l'errore oppure usi un
metodo più raffinato?
io, nel mio prj, installo tutte le DLL indipendentemente dal tipo di
installazione,
poi ho delle variabili booleane che indicano quando una certa funzionalità è
disponibile o no.....
ma non mi piace molto fare le cose così......
tu come fai esattamente?
grazie!!!!
--
Damiani Liborio Igor
ig...@igordamiani.it
 - 
dam...@italiainfiera.it
 - 
idam...@hotmail.com
http://www.igordamiani.it
ICQ : 11847262

 grazie!!!!
prego!


mi piace come idea........
1) che software usi per il setup del modulo?
2) per modulo tu intendi una DLL ActiveX, giusto?
io uso Visual Installer, e dovrei vedere se riesco a installare come dici
tu, cioč se in fase di installazione riesco a scrivere nel registro qualcosa
che mi indichi quando un modulo c'č o no.....
forse con i MSM......mmhhh......
vabbč, dai, adesso sto andando OT........
good coding!!!


 good coding!!!
Anche a te, ciao!


 ma non mi piace molto fare le cose così......
[SNIP]
Un altre sistema, leggermente piu' laborioso all'inizio ma con il quale ci
troviamo bene, e' quello di avere, per ogni DLL satellite, un unico sorgente
ma *due* progetti: il primo completo, il secondo con le medesime classi
pubbliche (per essere compatibile con il primo) il cui codice pero' viene
escluso, insieme agli altri moduli ecc.. tramite una costante di
compilazione condizionale (quindi nessuna duplicazione di file o di parti di
codice).
La classe principale della dll espone tra le altre una property che indica
se la versione attualmente istanziata e quella completa o meno, qualcosa del
tipo:
Public Property Get FullVersion() As Boolean
#IF FULL Then
    FullVersion = True
#Else
    FullVersion = False
#End If
End Property
I vantaggi del sistema sono:
early-binding senza problemi; dato che sara' sempre installata o la versione
completa o quella ridotta del componente, tra loro in compatibilita'
binaria.
nessun bisogno di configurazioni esterne (file, registry & c.), per decidere
cosa attivare e cosa no; basta mettere la dll giusta, e lei stessa segnala
la sua disponibilita'
nessun pericolo di utenti "furbi", perche' materialmente il grosso del
codice non c'e', quindi non possono attivare nulla di piu'
un controllo piu' fine sulle funzionalita' da attivare, e la possibilita' di
mantenere uniforme la logica principale dell'applicazione principale.
Con quest'ultimo punto mi riferisco principalmente alla possibilita' di
evitare situazioni di "o tutto, o niente"; a volte puoi avere necessita di
aver a disposizione alcune funzioni specifiche di una DLL anche quando
l'utente non ha acquistato il pacchetto completo; piuttosto che duplicare
tali operazioni nell'applicazione host o altrove, non fai altro che lasciare
intatto il codice corrispondente anche nella versione ridotta, semplicemente
giocando con la costante di compilazione condizionale vista prima
Allo stesso modo, molte verifiche possono essere fatte direttamente dal
componente; quindi per esempio il programma host chiamera' sempre e comunque
il metodo X; nella versione full rispondera' in un modo, nella ridotta
magari restituira' sempre errore (oppure sempre "ok" senza fare nulla) e
cose di questo genere che aiutano a mantenere piu' "pulita" l'applicazione
principale
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown


Ma non bastano dei file .exe standard che vengono lanciati con una SHELL o
simili e se non mi serve il modulo lo cancello?
Paolo


 renderlo modulare.
- LA PAROLA AL NIUBBO -
Dico la mia da bravo niubbettino ^_^
ho una applicazione mdi con menu a destra , ogni voce e' un modulo , ogni
modulo non e' altro che un gruppetto di form e moduli
ora apro un progetto nuovo e inserisco le formcomuni e poi aggiungo man mano
form di ogni modulo che voglio istallare , all'avio costruisco la barra dei
moduli testando se frmModuloNome esiste o no !
.Quando devo creare l'exe posso scegliere le form che mi servono :
le funzioni comuni sono su un modulo generale insieme al form mdi , il resto
e' del tipo :
modCiccio
frmCiccioMain
vantaggi : avere TUTTO il codice a disposizione per qualsiasi piccola
modifica
svantaggi : si deve cambiare il codice dal progetto completo e poi
ricompilare con i progetti secondari e a volte sovrascrivo qualcosina che
non dovrei ^_^;

Anche io ho sviluppato il software cosě (progetto EXE + diverse DLL ActiveX)
perň mi sorge un problema:
quando faccio delle modifiche ad una dll e poi la rimando al cliente,
puntualmente si verifica l'errore 429.
Ho provato anche con regsvr32 /u MiaDll.dll e poi a registrare di nuovo la
dll.... ma niente! L'unica cosa č rispedire anche il file EXE.
Chi mi da qualche consiglio? Grazie
VincePik

 ha scritto nel messaggio
news:YVR0a.145421$0v.41...@news1.tin.it...

uno sono: compatibilita' binaria.
Cerca l'argomento sulla guida; va applicato alle DLL...
