Newsgroup: it.comp.appl.access
Titolo: Come fare per avere libreria funzioni/procedure comuni tra tanti programmi ?

Man mano che si sviluppano progetti diversi ti accorgi che moltissime 
funzioni e procedure vengono riutilizzate
Attualmente copio brutalmente i moduli da un progetto all'altro, operazione 
che anche l'uomo di neanderthal definirebbe "..da grezzo e preistorico.."
Cosi' facendo si perde traccia della modifica piu' recente o comunque non si 
e' mai sicuri di aver preso la funzione dal progetto/modulo giusto
Nel senso che, se hai gia' realizzato il progetto A ed inizi il progetto B 
copiando alcune funzioni dal progetto A, quando modificherai qualcosa su 
queste ultime, il progetto A non ne risentira' e quindi tutti i 
miglioramenti apportati dovranno essere riportati a manina sui progetti 
'padri' del progetto B
C'e' anche il rovescio della medaglia, nel senso che se tenessi un file .MDB 
come repository del codice comune, nei riferimenti di qualsiasi nuovo 
progetto, quando dal programma B cambio qualcosa su una funzione comune, ne 
verra' influenzato anche il progetto A, mio malgrado
Mi chiedevo come fate voi per mantenere una sorta di 'libreria' del codice 
che viene riutilizzato piu' spesso o quale ritenete possa essere la via 
migliore per raggiungere i seguenti obiettivi:
- avere sempre disponibili le funzioni aggiornate all'ultima versione
- non compromettere il funzionamento dei progetti realizzati con versioni di 
codice pubblico antecedente all'ultima versione
Ciao e grazie
RobertoA

 che viene riutilizzato piu' spesso o quale ritenete possa essere la via
Il sistema piu' spiccio e semplice e': anziche' importare il modulo,
lo colleghi come riferimento dal meni strumenti-riferimenti.
cia'
Max

 lo colleghi come riferimento dal meni strumenti-riferimenti.
Programma A.MDB, colleghi come riferimento il file MODULI_COMUNI.MDB ed usi 
delle funzioni contenute in quest'ultimo
Poi, avvi il progetto B, che usera' come parte principale il file B.MDB e 
colleghera' come riferimento MODULI_COMUNI.MDB
Per esigenze di B devi aggiungere un parametro in ingresso ad una funzione, 
prima aveva solo un parametro in ingresso ora ne avra' due
Il progetto B funziona perfettamente
A questo punto se avvi il progetto A non funzionera' piu' correttamente in 
quanto la funzione che prevede due parametri in ingresso verra' chiamata 
usando un solo valore come parametro
Como se po' ffa' ?
Ciao
RobertoA

 Como se po' ffa' ?
Dichiari il secondo parametro come optional.
cia'
Max

 Dichiari il secondo parametro come optional.
Era un esempio per far capire che man mano che utilizzi il codice comune, i 
progetti piu' vecchi ne risentiranno perche' inevitabilmente presumeranno di 
'vedere' il codice comune come era stato scritto in origine
Ho fatto l'esempio del numero parametri di ingresso ma potrebbe essere il 
tipo di valore ritornato da una funzione
Una volta mi e' capitato che il lotto di un prodotto fosse di tipo numerico, 
poi su un altro sistema (che usava una funzione del codice comune) e' stato 
necessario definire il tipo come stringa alfanumerica, in quel caso 
modificare il tipo ritornato dalla funzione "damme_el_lotto() as long" in 
tipo alfanumerico avrebbe impedito al progetto iniziale di funzionare (come 
e' successo)
Ero curioso di capire se esiste qualche prodotto o metodo particolare per 
ovviare a questo tipo di problemi
Ciao
RobertoA

 ovviare a questo tipo di problemi
Riguardo la gestione del codice, mi sono rotto le corna anch'io
qualche mese fa, ed avevo iniziato a scrivermi un modulo contenente
funzioni per l'aggiornamento degli altri moduli in un db, usando non
un .mdb come 'repository' ma un server svn (con relativo client da
command-line) per delegargli il versionamento ed altre cose.
Ho lasciato perdere quando ho letto che le versioni Developer di
Access hanno un gestore integrato per questo, e sto aspettando Access
2007 developer.
Per quanto riguarda l'uso di funzioni che, a parità di nome, possono/
devono dare risultati differenti -compresi i datatype restituiti, come
nell'esempio che hai fatto- credo che in Access si possano usare solo
palliativi.
Potresti astrarre tutte le funzioni che usi (invece di
damme_el_lotto() usi meta_lotto("damme_el_lotto", "parametri vari"). A
questo punto è meta_lotto() che in base alla STRINGA di parametri (che
devi occuparti di parsare a dovere), decide cosa deve fare; con tutto
quel che ne consegue in termini di mantenibilità del codice.
Oppure ti astrai comunque, creando però classi dove al loro interno
implementi parametri e funzioni ad hoc per fare una sorta di
overloading / overriding (cosa questa che con l'Access 97 che uso non
mi sono ancora sognato di fare).
Anche questa scelta ha i suoi pro e i suoi contro, a cominciare dal
fatto che nelle query le classi non sono accessibili direttamente e
devi tornare alle funzioni.
ciao,
Panathos

 ovviare a questo tipo di problemi
Riguardo la gestione del codice, mi sono rotto le corna anch'io
qualche mese fa, ed avevo iniziato a scrivermi un modulo contenente
funzioni per l'aggiornamento degli altri moduli in un db, usando non
un .mdb come 'repository' ma un server svn (con relativo client da
command-line) per delegargli il versionamento ed altre cose.
Ho lasciato perdere quando ho letto che le versioni Developer di
Access hanno un gestore integrato per questo, e sto aspettando Access
2007 developer.
=================================
Posso sapere dove hai letto questa cosa su Access Developer ?
Ciao e grazie
RobertoA

 Posso sapere dove hai letto questa cosa su Access Developer ?
Il buon Costarella mi chiese se avevo Visual SourceSafe:
http://groups.google.it/group/it.comp.appl.access/msg/0d6ae69f3eb91780
Siccome manco sapevo cosa fosse, ho trovato questa pagina:
http://www.microsoft.com/italy/msdn/prodotti/ssafe/default.mspx
Mentre per l'integrazione fra Access 2007 e VS faccio riferimento a
questa:
http://office.microsoft.com/en-us/access/HA102092361033.aspx
ciao,
Panathos