Newsgroup: it.comp.lang.vo-clipper
Titolo: repository

Salve, dopo aver finito il mio primo programma di fatture in VO, iniziero`
(se ci riesco) a fare un programma per gestire una fresa che dovrebbe
incidere circuiti stampati.
Dato che prevedo che il programma sara grande mi e` venuto un dubbio sul come
gestirlo nel repository.
Sicuramente mi conviene creare un progetto nel quale mettere il tutto.
1) Potrei creare una applicazione contenente tanti moduli
   es. applicazione "lavoro"
        modulo       form clienti
        modulo       dbserver clienti
        modulo       metodi clienti
        modulo       form frese
        modulo       dbserver frese
        ecc ecc. 
2) Potrei creare applicazione principale e poi altre che gestiscono le
   varie fasi
   es. applicazione "lavoro"
        applicazione clienti
         modulo      form clienti
         modulo      dbserver clienti
         modulo      metodi clienti
        applicazione frese
         modulo      form frese
         modulo      dbserver frese
        ecc ecc.
Come si vede nel secondo caso esiste una applicazione lavoro nella quale dovrei
linkare le altre applicazioni.
Secondo me la seconda e` la migliore ma ho avuto problemi con le classi.
Quando creo una datawindow o dbserver o altro  e cerco di subclassare non mi
vengono mostrate le classi possibili ed allora devo scriverle a mano.
Con il primo caso non ho nessun problema.
Quale mi consigliate?
Grazie. 
-- 
Remove XXX for reply. Rimuovi XXX per rispondere.

 wrote in message
slrn9ddm...@localhost.localdomain...


anche con eseguibili ragguardevoli che superano i 3 Mb di dimensione!
Come hai suddiviso le dll ??
Tutti i form in una dll, tutti i dbserver in una dll ecc. ??
Oppure tutta la gestione clienti in una dll, ecc ??
Ciao


 ha scritto nel messaggio
news:slrn9dml...@p129.trieste.adriacom.it...


 ha scritto nel messaggio
news:slrn9ddm...@localhost.localdomain...



Anch'io adopero un'organizzazione simile: in una DLL "di basso
livello" aggiungo tutti i moduli fondamentali, che via via creo e che
risultino di utilità per tutti i programmi che sviluppo (es.  i metodi
e le classi per la gestione bufferizzata dei dati, le interfacce con
la porta seriale, le funzioni particolari etc.) In una libreria di
classi semi-autonome invece tengo dei moduli programma che svolgono
funzioni complete già definite (p. es. un generatore di filtri
standard, un generatore di incroci tra campi di database relazionati
etc.). Questi moduli con quelli di basso livello, entrano a far parte
dell'eseguibile finale. Questa organizzazione funziona bene, comporta
uno sforzo supplementare nel rendere i moduli slegati dal contesto di
uno specifico programma, per renderli utilizzabili anche in altre
situazioni (per questo viene in aiuto la OOP di CAVO con
l'ereditarietà delle classi). Vorrei anche dire che il repository di
CAVO risulta uno strumento eccezionale per gestire le modifiche alle
DLL o alle librerie di uso generale: un cambiamento ad una di queste e
il programma segnala automaticamente tutti i moduli in uno qualsiasi
dei programmi presenti (nel repository stesso) interessati dalla
modifica.
Marino

Salve,
mi sono posto questo problema già parecchie volte, ed ho anche 
contattato la CA su questa tematica.
Sul discorso: .exe monolitico oppure .exe piccolo e più .dll.
Secondo me è da preferire il file .exe monolitico perchè usando delle 
DLL VO include tutte le classi e metodi delle DLL linkate nel file 
exe. Ho fatto una piccola prova tempo fa di un mio applicativo:
la mia agenda come .exe monolitico occupa circa 2,5 mb e in usa 12224k 
di memoria.
creando un .exe "piccolo" quello è grande circa 1,2 MB, comprese le DLL 
necessarie sono oltre 5 MB. In memoria occupa 13696k.
Devo però dire che ho dei moduli che non sono sempre in uso (accesso a 
Jet, modulo Zip, modulo VOScript, modulo report). Questi moduli sono 
creati come DLL, e non sono referenziati nel programma principale. 
Quando mi serve una delle classi in una di queste DLL, le carico e use 
le classi con CreateInstance. Questo funziona molto bene.
sul discorso: organizzazione repository:
uso 8 progetti (projects) differenti. Le mie librerie principali che 
uso in quasi tutti i progetti sonos composti esclusivamente da moduli 
"esterni" a VO. Modificandoli in un progetto, saranno modificati 
automaticamente anche negli altri nella prima compilazione. 
Purtroppo questo non funziona con le entità binarie (finestre), ma per 
fortuna li le modifiche non sono molto frequenti. Devpo aggiungere che 
per tenere basso il codice in uso rinuncio al server editor da quasi 
cinque anni, e cerco di scrivere meno codice possibile.
Saluti
WOlfgang
Merano

>         ecc ecc.
Nella applicazione "lavoro" linko le altre 2 applicazioni (clienti e frese).
Ho provato con questa tipologia ma ho avuto problemi con le classi.
Quando creo una datawindow o dbserver o altro  e cerco di subclassare non
mi vengono mostrate le classi possibili ed allora devo scriverle a mano.
Questo sistema l'ho provato con la versione 2.5 liscia prima di aver
installato le patch. Riprovero` di nuovo, e che queste cose si possono fare
solamente quando si inizia un nuovo progetto, percui e` importante decidere per
tempo.
In ogni caso alla fine avro` un solo .exe che conterra` il tutto (ovviamente).


 >ottimale ma sembra funzionare bene e il programma è logicamente e


Antonio
Era proprio questo il problema, alcune volte nell'inherit from non
comparivano le classi che avevo creato.
Altro problema.
Nella mia prima applicazione ho creato una variabile globale (matrice) con
alcuni DEFINE.
es.
#DEFINE PAGINA := 100
Poi uso if a[PAGINA] = 100 ; ecc ecc.
Se divido l'applicazione di sicuro i DEFINE devo riscriverli in ogni sub
applicazione.
Mi conviene continuare con questa tecnica oppure ne esistono altre migliori ??
P.S. fin ad adesso ho una variabile globale a 20 elementi.
Ciao


 ha scritto nel messaggio
news:slrn9e91...@p422.trieste.adriacom.it...


Ciao, Antonio
Non ci avevo pensato di usare le variabili STATIC.
Ciao
-- 
