Newsgroup: it.comp.lang.visual-basic
Titolo: Come organizzare un'applicazione "a progetti"?

Salve a tutti,
uso vb solo per hobby e mi diverto nel crearmi applicazioni che mi aiutino 
nel mio lavoro quotidiano.
Fino ad ora ho sempre realizzato semplici applicazioni che lanciate avevano 
al massimo un loro menů che dava
accesso a diversi form ognuno dei quali eseguivano operazioni.
Ora vorrei provare una cosa un pň piů complessa per la quale perň non so da 
che parte cominciare.
Provo a spiegarmi.
L'applicazione dovrebbe funzionare strutturalmente come excel cioč:
- applicazione (excel)
- un "progetto" (file excel)
- dentro ogni progetto altri sotto-progetti (tipo i fogli di excel);
Il problema č che non so nemmeno cosa cercare in rete per iniziare a 
lavorarci.
Potete indirizzarmi?
Grazie in anticipo. 

 
Siccome quello che hai scritto può essere interpretato in vari modi,
prova a fare un esempio di cosa vuoi fare veramente.
Nicola

Grazie per l'attenzione Nicola,
provo a spiegarmi meglio con un esempio.
Devo fare delle verifiche di elementi strutturali, solai, scale, travi 
etc...
Quindi ho un cantiere di riferimento e all'interno del cantiere devo fare le 
verifiche di 3 elementi (solai, scale, travi). All'interno di ogni elemento 
poi potrň aver N tipologi (esempio 10 solai, 5 travi... etc).
Riassumendo:
1. progetto - cantiere;
2. dentro al progetto - un form per ogni "elemento" (solaio, scale, travi);
3. dentro ad ogni elemento potrei avere diverse tipologie (10 solai, 5 travi 
etc...)

 etc...)
Non so se può esserti utile, ma io gestirei la cosa in questo modo:
1-Anagrafica cantieri che contiene la lista di tutti i cantieri aperti.
2-Anagrafica progetti, lista dei progetti collegati ad uno specifico
cantiere
3-Anagrafica elementi, lista degli elementi collegati ad uno specifico
progetto.
Come interfaccia utilizzerei una treeview:
HOME
 |-Cantiere1
   |-Progetto1
     |-Solaio1
     |-Trave1
     |-Trave2
     |-Scala1
   |-Progetto2
     |-Solaio1
     |-Solaio2
     |-Solaio3
     |-Trave1
     |-Trave2
     |-Scala1
 |-Cantiere2
   |-Progetto1
     |-Solaio1
     |-Trave1
     |-Trave2
     |-Scala1
 |-Cantiere3
   |-Progetto1
     |-Scala1
   |-Progetto2
     |-Trave1
     |-Trave2
     |-Trave3
Quando clicchi su uno degli elementi ti si apre un form con le
informazioni dell'elemento.
Se vuoi aggiungere un nuovo Cantiere ti posizioni su HOME e con un
menu/pulsante/menu contestuale lo crei.
Idem per i progetti legati ad un cantiere: ti posizioni sul cantiere del
quale vuoi creare un progetto e con un menù lo crei.
eccetera eccetera...
Nicola

 cerco, treeview o altro?
VB6 o .NET?


Per VB6 io partirei dal Sito Comune del newsgroup:
http://www.it-lang-vb.net/archivio.asp?subMenu=Tutte&FullText=on&TypeRic=AND&keyword=treeview
Per .Net trovi molti esempi cercando ".NET Treeview" su google.
Ciao,
Nicola

 Per .Net trovi molti esempi cercando ".NET Treeview" su google.
Grazie,
ciao 

Nicola,
scusa se approfitto della tua disponibilità...
ma, ok per il treeview (mi sto documentando), puoi consigliarmi anche cosa 
cercare riguardo l'archiviazione dei dati?
Cioè io avrò il mio "cantiere", i miei progetti e le mie strutture.
Ovviamente dovrò salvarli in qualche modo da qualche parte.
Fino ad ora in altri lavori (sempre ad utilizzo personale e per hobby quindi 
con pochissime pretese ma grande soddisfazione) ho utilizzato sempre e solo 
database ma stavolta vorrei evitarlo.
Quindi, sempre rimanendo nell'ambito, cos'è che dovrei cercare riguardo 
l'archiviazione ed il richiamo dei dati di un progetto su file creato 
appositamente?
Grazie infinite.

 appositamente?
Se vuoi cimentarti nel salvataggio su file (un pò come avviene per
Excel) sta a te decidere cosa salvare e in quale struttura.
Puoi usare un file di testo piano, puoi usare un XML o altro...
Io personalmente salverei tutto in XML, ma devi imparare a gestirli,
perchè all'inizio sono un pò ostici, ma hanno grandi potenzialità.
Puoi iniziare da qui:
http://support.microsoft.com/kb/317661/it
Nicola

 etc...)
Spacca il progetto indipendentemente dal linguaggio che usi in
elementi funzionali
Leggendo anche sotto a te non manca l'implementazione....manca
l'analisi!
Visto che siamo in tema....prima del tetto...le fondamenta...ma prima
ancora di quelle...il progetto!
Ce l'hai un progetto? ...alias una analisi del problema che ti
chiarisca COSA programmare??? Sembrerebbe di no!
A "cazzotto in cielo" (modo di dire toscano che vuol dire in linea
molto teorica e generale)
Spacca il problema in 3 strati:
Interfaccia....COME MOSTRO i risultati e come raccolgo l'input
dell'utente
Business....come trasformo i dati...ad esempio le formule per
calcolare una trave
Database....dove memorizzo i dati?...
Da li vedi che hai bisogno di 3 analisi separate ognuna con i suoi
problemi e soluzioni.
Ad esempio...io vedrei bene una struttura di database relazionale dove
hai la tabelle principale progetto che relaziona altre tabelle....ad
esempio io ho un amico architetto che può avere UN progetto e PIU'
cantieri...
Come vedi è un problema di analisi delle tue specifiche esigenze
Una volta chiarito tutto....
realizzi il database (puoi usare access...e sfruttare la sua
comodissima interfaccia...in una massimo 2 giornate hai una struttura
db che con dati di prova ti chiarisce relazioni e eventuali
dimenticanze o incongruenze)
Una volta chiarita la struttura db....scegli il database...lo realizzi
(quindi scegli se usare un database : mySQL Access, SQlite, SQLserver,
etc)
realizzi uno strato che si connette al database (ovverosia realizzi
una serie di classi o libreria di funzioni....per recuperare i dati
dal database)
QUESTO è comodo! E ti inviterei a perderci tempo!
Avere una funzione RecuperaProgetto(IDprogetto) ti svincola dal
database...metti che la tua applicazione ha successo ed access diventa
piccolo...è INDOLORE sostituire il database!
Anche avere una funzione CercaDato (Tabella, Dato) altrettanto!
Fatti poi una serie di routine ...classi quello che è...che
trasformano i dati
CalcolaTrave...StampaProgetto...etc etc
Da ultimo...l'interfaccia.....ossia un altra serie di routine classi
quello che è che prendi i dati e li mostra e fa anche l'incontrario:
raccoglie l'input e (eventualmente validandolo) lo passa a quello che
c'è dietro.
Anche qui:
Se hai una funzione/classe/quello che è
MostraDipendenzeProgetto(Nomeform)
userai quella per impostare da runtime (palloso ma comodissimo) i vari
elementi della form e valorizzarli.
Comodo...perchè se vuoi cambiare l'interfaccia...ed i tuoi clienti te
lo chiederanno...potrai con POCA fatica cambiare la visualizzazione.
Questo è come si fà a grandissime linee un software con un  ciclo di
vita di qualche anno...come vedi si parte da avere le idee chiare...e
poi passo dopo passo si arriva all'implementazione!

Analisi profonda e dettagliata, forse la giusta pista da seguire quando si 
pensa di fare software. Purtroppo le incognite sono tante, e quelle vengono 
fuori durante la realizzazione del progetto.  Ti sei dimenticato di fare 
quella routine di controllo, oppure hai mancato quel bottone che potrebbe 
essere utile in quella occasione. Bene...........da questo momento in poi, 
il tuo superlavoro inizia a diventare una vera e propria schifezza, con 
funzioni sparse un po ovunque per cercare di realizzare quello che non avevi 
pensato fin dall'inizio.
Riepilogando, mi chiedo se esiste qualcuno che riesce a pensare veramente a 
tutto, quando si inizia a lavorare ad un progetto e quando parlo di tutto 
intendo fin nei minimi particolari. Personalmente non ci riesco, ma son 
sicuro che il mio approccio è sbagliato, vengo dalla scuola dove si vuol 
vedere qualche cosa funzionare e lo si vuol vedere anche subito.
Enzo


 anche subito.
Un software, a meno che non sia abadonware, è un cantiere continuo.
Questo però non significa che non si possa pianificare correttamente
l'attività di manutenzione evolutiva del programma.
Tutto sta a come imposti il lavoro.
Nicola