Newsgroup: it.comp.lang.visual-basic
Titolo: DLL, COM? Suggerimenti?

Ciao a tutti!
ho qualche domandina di analis/disegno di un programma....
devo fare un programma che ha vari moduli disponibili, quando il cliente
decide compralo sceglie i moduli che desidera (e quindi cambia il costo del
programma).
Al momento c'é tutto dentro il programma, con una password speciale posso
abilitare/disabilitare i moduli che voglio; problemi: é tutto dentro il
programma, l'exe sta diventando grandino (3.7 Mb e crescendo ogni giorno),
se il cliente scopre la pwd puó rubare tutti gli altri moduli (che valgono
circa US$ 2,000), se aggiungo un nuovo modulo devo ricompilare tutto di
nuovo.
Stavo pensando nella possibilitá di avere dei files esterni che svolgono il
ruolo di ogni modulo, se non c'é il file esterno non vi é modo che il modulo
possa funzionare.
Ho considerato l'idea degli ActiveX DLL, ma se ben capisco, questi hanno
bisogno di essere dichiarati nell'applicazione, quindi, se aggiungo un nuovo
DLL devo ricompilare comunque, corretto?
Qualcuno con un bel po' di esperienza mi ha consigliato COM, Common Object
Model, che al momento é come arabo per me; prima di cominciare a studiare
nuove tecnologie, mi piacerebbe ricevere opinioni al rispetto....
Grazie per tutto!!
Alejandro
domy...@hotmail.com
Santo Domingo
Rep. Dominicana

 ho qualche domandina di analis/disegno di un programma....
....
Non sò come sono fatti i tuoi moduli comunque, potresti installare i vari
ActiveX senza dichiararli all'interno del progetto, in modo che VB non li chieda
durante l'avviamento del programma, poi quando ti servono, inizializzarli con
CreateObject come in questo esempio :
dim obj as object
Set obj = CreateObject("NomeActiveX")
dove NomeActiveX è il nome del tuo ActiveX.
A questo punto puoi utilizzare i metodi e le proprietà dell'oggetto creato e
posto nella variabile OBJ. Attenzione perchè se l'oggetto ActiveX non è
installato nel sistema VB indica l'impossibilità di crearlo e termina
l'esecuzione del programma.
Ciao
Roberto


Trappable error, ci metti un bell'
Sub MySub()
    On Error GoTo error_handler
    ' ...
    ' codice della sub
    ' ...
    Exit Sub
error_handler:
    ' codice dell'error handler, direi :
    If Err=OBJECT_NOT_FOUND Then
        ' OBJECT_NOT_FOUND te la definisci sopra come costante,
        ' fai una prova con una CreateObject fasulla per averne il valore
        MsgBox  "Il modulo richiesto non e' installato.", vbExclamation
    Else
        MsgBox "Si e' verificato il seguente errore: " & vbCrlLf &
Err.Description, vbCritical
    End If
End Sub
e ne esci vivo.
Il problema e' sulle prestazioni di oggetti late-bound, ci vuole un po' a
crearli e ad accedervi, percui dovresti almeno crearli una sola volta, tipo
al form_load.
Inoltre hai il problema in design-time che non puoi usare l'IntelliSense per
sapere con che tipo di oggetto stai lavorando... In questo caso potresti
cercare di ridurre i danni usando oggetti con un'interfaccia implementata
(crei l'interfaccia, vuota, e la metti in una DLL che e' sempre presente,
poi usi una Implements in ogni modulo aggiuntivo).
Il programma a quel punto assegna l'oggetto con una CreateObject(),  ma hai
il vantaggio di avere una definizione specifica del tipo di oggetto che ti
evita anche possibili errori di coding.
Va da se' che se aggiungi un modulo totalmente nuovo devi rilasciare anche
la DLL con le definizioni (mantenendola compatibile con la vecchia
versione), pero' cmq dovresti rilasciare il nuovo EXE (che deve usare il
nuovo modulo) quindi rilasci tre file anziche' due; non e' un grande sforzo
(le definizioni ono piccole) e ti aiuta a lavorare meglio.
Ciaotutti,
Alessandro