Newsgroup: it.comp.lang.visual-basic
Titolo: [VB6] Librerie DLL (tosto, lunghetto)

Ciao a tutti,
ecco il problema:
ho scritto delle DLL che uso frequentemente nei miei progetti e nelle
quali ho raccolto parecchie funzioni personali (stampa griglie, input
utente controllato, manipolazione stringhe eccetera).
Poiché ho due PC, uno che uso a casa per programmare e un portatile
che uso per le installazioni presso i clienti ho il problema di
sincronizzare i dati fra essi.
Ho risolto con un piccolo programma mio di trasferimento file che fa
esattamente quello che mi serve e lo fa egregiamente; è un po'
complesso, ma in sostanza il tutto si traduce in una sovrascrittura di
file dal PC fisso al portatile o viceversa (anche presso il cliente
spesso devo fare piccole modifiche "volanti").
Fin qui tutto okay, il problema è che sovrascrivere gli EXE e le DLL
compilando indistintamente sul PC fisso o sul portatile dà luogo a
parecchi evidenti problemi di registrazione delle DLL.
Ho risolto quasi totalmente effettuando tutte le compilazioni SEMPRE e
SOLO su un computer, mai sull'altro (ovviamente sul portatile, perché
è normale che il cliente chieda modifiche all'ultimo secondo e quindi
mi serva una ricompilazione presso di lui).
Però... però anche questa soluzione dà qualche problema: le DLL
vengono SEMPRE riconosciute sia dagli EXE che nell'IDE di VB, però
quando devo passare loro non semplici tipi di dati (Long, String...)
ma oggetti ActiveX (es. FlexGrid da stampare o altro) si verifica un
errore nell'IDE : VB non riconosce correttamente l'oggetto passato
alla DLL.
Per completezza preciso che non passo gli oggetti alle DLL
direttamente (VB non lo consente), ma li passo come Variant e poi
nella DLL vengono riassegnati ad una variabile dichiarata
correttamente (per avere ancora funzionante il comodo IntelliSense per
metodi e proprietà).
De-registrando e ri-registrando (regsvr32) le DLL il problema non si
risolve.
Ripeto: il tutto si verifica solo con il passaggio degli ActiveX.
Ovviamente tutto funziona bene se le DLL vengono compilate sullo
stesso PC, il problema è quando le DLL vengono compilate su un PC e
poi usate in un altro.
Che si può fare?
Bye!

 Bye!
Domanda: quando compili quale compatibilità indichi?
Hai provato con quella binaria?
Quando ti chiede di indicare il percorso del file eseguibile che contiene la
versione precedente del componente dovresti fornirgli sempre il percorso al
medesimo file, in sostana ti devi creare una sorta di modello di riferimento
per la ricompilazione.

 per la ricompilazione.
Sì, sì, questo lo faccio.
Mah, proverò a passare alla compatibilità binaria, anche se avrei
preferito evitare.
Grazie per la risposta,
Ciao!

aggiornate al 100%.
Spero che tu provveda preventivamente a deregistrare i componenti
vecchi, altrimenti sai che casino nel registro degli utenti :-(
-- 
ciao, hal

 vecchi, altrimenti sai che casino nel registro degli utenti :-(
Questa non l'ho capita...
Sui vari manuali VB c'è scritto che è VB stesso a deregistrare e poi
ri-registrare i componenti ogni qualvolta sia necessario. Non è così?
Provo a spiegarmi meglio.
Per mantenere la sincronizzazione fra i due PC compilo sempre su uno e
poi semplicemente sovrascrivo le DLL sull'altro. La stessa cosa faccio
sui PC dei clienti, con la differenza che qui va tutto bene (dai
clienti): le DLL funzionano correttamente al 100%, mentre sul mio
secondo PC, quello dove non compilo, funzionano al 90%, cioè è tutto
ok tranne quando il codice passa dei componenti ActiveX: non me li
riconosce e dà errore (l'oggetto passato non è del tipo xxx che stavo
aspettando).
E' questo errore che non comprendo.
Per quanto riguarda la de-registrazione, non la faccio semplicemente
perché non faccio nemmeno la ri-registrazione. Il RegSvr32 non lo uso
proprio: la sovrascrittura delle DLL è tutto quello che serve (almeno
sul computer dei clienti)... però non funziona al 100% sul PC di
sviluppo, dove non compilo.
Spero stavolta sia chiaro, oppure non ho capito io l'intervento.
Grazie comunque e ciao,
Carlo.

 sviluppo, dove non compilo.
che strano , cmq cerca "Compatibilita' binaria" nei post vecchi ! per me e'
successo questo :
sui clienti hai istallato il programma e il setup ha registrato l'ax
versione 3.1 per esempio , sul pc in cui sviluppi e' ancora registrata una
2.7 per esempio e NON MANTIENE la compatibilita' binaria !
se le dll sono fatte in vb6 sarebbe meglio registrarle ad ogni aggiornamento
!