Newsgroup: it.comp.lang.visual-basic
Titolo: Strumenti visuali di Visual Studio

Ciao a tutti,
sto programmando da poco in VB.Net e, purtroppo non riesco a capire la
filosofia  di funzionamento deli strumenti grafici visuali.
Probabilmente voi che ci lavorate da un bel pezzo riuscirete a
chiarirmi un po' meglio la faccenda.
In pratica mi sono creato un'applicazioncina che lavora su un db
collegato via odbc e sembra funzionare benino. Il "problema" è che ho
creato tutto da codice (intendo i vari dataset, datatable, connection
ecc...). Quello che non mi è chiaro è se è meglio programmare
creandosi tutti questi elementi utilizzando gli strumenti visuali
messi a disposizione da visualstudio o se è conveniente procedere come
ho fatto io. 
Mi sono accorto per esempio che, se avessi creato tutti i dataset e le
datatable in modalità grafica, adesso che devo creare i report con
crystal report, sarei molto avvantaggiato o, per esempio per collegare
gli items di una combo ad una datacolumn, è molto più rapido farlo
dalla finestra proprietà che è altrimenti inutilizzabile (?) creando i
dataset da codice istanziando a mano le classi.
Boh? ho un  po'  di confusione in testa, se qualcuno è in grado di
farmi un po' di chiarezza lo ringrazio molto.
Ciao, Michele

 ha scritto nel messaggio
news:jaafhvolo961knhva...@4ax.com...
...
Gli strumenti visuali nascono come "scorciatoia" per lo sviluppatore: se, ad
esempio, usi i "controlli" per gestire un database (o un menu, o un button),
l'IDE scriverà, nella Region "Designer Generated Code", lo stesso codice che
avresti scritto tu.
Ovviamente scrivere il codice da sé, oltre che didattico, dà un controllo
più approfondito. Se del controllo approfondito non hai che fartene e ti fa
comodo l'"integrazione", be', abusa pure della toolbar.

beh, questo è strano........di solito chi si avvicina a VB prima giocherella
un po' con i vari strumenti visuali.
Parlando di db, all'inizio io uso tutti controlli data-bound, simulando il
più possibile quello che avveniva nelle mie app Access.
però ho visto che era lento, e avevo poco controllo.....
quindi ho cominciato a scrivere codice, che è sicuramente più lungo, più
"difficile" e lento, diciamo, però hai sicuramente maggiori performance e un
controllo più accurato.....
tu invece hai fatto esattamente il contrario....da un certo punto di vista
ti ammiro.....
:-)))
effettivamente, se devi disegnare report, ti conviene avere i vari dataset e
i datatable creati in progettazione con .NET, e usando questi ottieni la
base per disegnare i report in maniera intelligente......
poi, hai due possibilità, secondo me: o li tieni, e quindi il tuo exe finale
sarà un po' più grande, oppure li cancelli, ma in run-time devi occuparti di
passare ai report un dataset uguale a quello che avevi usato in
progettazione.......
altra cosa: per le combobox, ad esempio, io popolo tutto a manina, nel senso
che ho creati una sub a cui passo il nome della tabella, il nome del campo e
il nome del controllo e lei fa tutto gli .AddItem necessari per popolare la
combox, senza usare alcuna caratteristica di data-bound.
ormai è questione di abitudine......
good coding!!!
-- 
Damiani Liborio Igor
ig...@igordamiani.it
 - 
soft...@igordamiani.it
 - 
idam...@hotmail.com
http://www.igordamiani.it
ICQ : 11847262

progettazione.......
Quindi, se non ho capito male, tu mi consigli di crearmi comunque le
tabelle e i dataset "copiandone" la struttura da quelle che mi
risultano dalle datatable via codice (chiaramente con nomi differenti
poichè non me le farebbe creare con lo stesso nome), ulizzarle per
creare la struttura del report e poi, al termine, sostiuire l'origine
dati del report con quella dei miei datatble o ottenuti a runtime dal
codice...
GRazie per i consigli!
Michele

sě, bravo......sei sveglio.....
:-))))
a parte scherzi, sě, intendevo questo.....se incorpora finestre di
progettazione (mi vengono in mente i dataenvironment e i datareport di vb6)
l'exe diventa molto grande, e non mi piacciono molto.....
meglio tutto via codice......


good coding!!!