[Visual Basic 2010] - Inizio adesso

[lucausa75]

Salve ragazzi,

ho programmato per molti anni in VB6 e da poco mi sto avvicinando a VB2010.
Prima di tutto volevo chiedervi se esiste la possibilità di scaricare degli esercizi a difficolta progressiva in modo da farmi pratico sull'utilizzo dei controlli, proprietà e metodi vari.

Volevo anche chiedere cosa significa questa check box che mi si presenta durante la fase di salvataggio di un progetto in VB2010:



e poi perchè l'icona è cambiata: vedi passaggio da 1 a 2




Grazie 1000!

[Kralizek]

allora, come in vb6 esistono i progetti. in aggiunta esistono le soluzioni che sono progetti collegati tra di loro.

quella checkbox ti permette di salvare tutto il codice da te prodotto in una cartella unica per la soluzione

per la seconda immagine: l'ambiente cambia automaticamente l'icona associata al file se capisce che la classe contenente deriva in qualche modo da Form.

[lucausa75]

Originariamente inviato da Kralizek

quella checkbox ti permette di salvare tutto il codice da te prodotto in una cartella unica per la soluzione

E' necessaria selezionarla?
Se all'inizio l'avevo selezionata c'è modo adesso di eliminare tutto ciò che questa selezione mi aveva creato?

Questa la sequenza delle cartelle createmi:

Originariamente inviato da Kralizek

per la seconda immagine: l'ambiente cambia automaticamente l'icona associata al file se capisce che la classe contenente deriva in qualche modo da Form.

Per questa ho risolto rinominando correttamente la classe col nome del form

...cmq passare da VB6 a VB2010 è davvero molto duro

[MarcoGG]

Originariamente inviato da lucausa75

E' necessaria selezionarla?

No, anzi. Quasi sempre, per non dire SEMPRE, ti conviene aver predisposto già una cartella con nome significativo del progetto, perciò se oltre a quello gli confermi che vuoi una directory per la solution, alla fine ti ritrovi la tua cartella con all'interno un altra cartella che contiene i files di progetto. Abbastanza inutile come cosa...

Originariamente inviato da lucausa75

...cmq passare da VB6 a VB2010 è davvero molto duro

Eh, e pensa a quanta gente ancora considera VB6 e VB.NET come zuppa & pan bagnato.
E' la sensazione che provano 99 sviluppatori VB6 su 100, ma poi vedrai che non riuscirai più a tornare a VB6.

[lucausa75]

Originariamente inviato da MarcoGG

No, anzi. Quasi sempre, per non dire SEMPRE, ti conviene aver predisposto già una cartella con nome significativo del progetto, perciò se oltre a quello gli confermi che vuoi una directory per la solution, alla fine ti ritrovi la tua cartella con all'interno un altra cartella che contiene i files di progetto. Abbastanza inutile come cosa...

Quindi non la seleziono più

Cmq sto notando adesso che non la seleziono mi crea solo una cartella con tutti i files del progetto (e questo è OK) e un file con estensione .sln (Microsoft Visual Studio Solution) :

Originariamente inviato da MarcoGG

...E' la sensazione che provano 99 sviluppatori VB6 su 100, ma poi vedrai che non riuscirai più a tornare a VB6.

Questa sensazione la ho già da ora che è da due giorni che ho messo mani a VB2010

[MarcoGG]

Originariamente inviato da lucausa75

Cmq sto notando adesso che non la seleziono mi crea solo una cartella con tutti i files del progetto (e questo è OK) e un file con estensione .sln (Microsoft Visual Studio Solution) :

Esatto. La Solution è un concetto nuovo rispetto a VB6.
Possono esistere Soluzioni multi-progetto. Ad esempio potresti decidere di avere un progetto principale "Programma_1", corredato da 2 progetti-satellite, "Libreria_1" e "Libreria_2", che di fatto potrebbero essere 2 dll di cui "Programma_1" fa uso...

Nella realtà però considera che la maggioranza delle Soluzioni sono mono-progetto, e nessuno vieta di creare una soluzione separata per ogni progetto che si desidera sviluppare, che sia .exe, .dll, ecc.

Il file .sln è proprio il punto di partenza, come in VB6 lo è "Progetto1.vbp". In soldoni, quello su cui fare doppio-click per aprire tutto in un colpo solo, Classi, Forms, Moduli...

[lucausa75]

Originariamente inviato da MarcoGG

Esatto. La Solution è un concetto nuovo rispetto a VB6.
Possono esistere Soluzioni multi-progetto. Ad esempio potresti decidere di avere un progetto principale "Programma_1", corredato da 2 progetti-satellite, "Libreria_1" e "Libreria_2", che di fatto potrebbero essere 2 dll di cui "Programma_1" fa uso...

Nella realtà però considera che la maggioranza delle Soluzioni sono mono-progetto, e nessuno vieta di creare una soluzione separata per ogni progetto che si desidera sviluppare, che sia .exe, .dll, ecc.

Il file .sln è proprio il punto di partenza, come in VB6 lo è "Progetto1.vbp". In soldoni, quello su cui fare doppio-click per aprire tutto in un colpo solo, Classi, Forms, Moduli...

Wow MarcoGG ma sei il guru..
Ti faccio adesso due domande:

1) Se cancello il file .sln il mio progetto funziona cmq?
2) Il progetto si avvia lanciando il file .vbproj o il file .sln?

Grazie ancora...

[MarcoGG]

Originariamente inviato da lucausa75

1) Se cancello il file .sln il mio progetto funziona cmq?
2) Il progetto si avvia lanciando il file .vbproj o il file .sln?

Grazie ancora...

1) Domanda curiosa. Perchè mai dovresti farlo ?
Assolutamente NO. Non lo fare. Non metterti a pasticciare adesso con i files di progetto. Sei all'inizio e non è proprio il caso.
E non cercare strane "analogie" tra Visual Studio 6 e VS 2010 ! Sono IDE profondamente diversi...

2) Come già detto sopra, lanci tutto a partire dal file soluzione .sln.

Ci sono tante, ma tante di quelle cose che devi ancora scoprire, molto più importanti. Anche se può sembrarti che VB 2010 crei davvero molti files, anche solo per un "Hello World", sicuramente molti più files di un analogo progetto VB6, per ora fai atto di fede, e vai oltre - mio giovane padawan -...

[lucausa75]

Salve ragazzi,
ancora una domanda:

se cancello tutto dalla sezione relativa il codice (2) l’icona del forma assume una forma strana (1) e fino a qui nessun problema ma mi chiedo come fare affinchè il codice riappaia?

Public Class frmMain


End Class

Poi volevo sapere come si fa a fare apparire l'utilissima finesta Immediate

[MarcoGG]

Ti stai ponendo problemi strani. Ma posso anche capire, visto che sei "traviato" da VB6. In VB 2010, e in generale in VB.NET post-VB6, devi per forza accettare il fatto che stai usando un linguaggio al 100% OO.

Perchè dovresti cancellare quelle righe, non l'ho capito, ma qui una Form è una Classe, che eredita da System.Windows.Forms.Form.

Tutto il codice che VS genera quando crei un nuovo progetto WinForms, lo devi prendere com'è e non toccarlo.

[MarcoGG]

Originariamente inviato da lucausa75

Poi volevo sapere come si fa a fare apparire l'utilissima finesta Immediate

Menu Debug / Finestre / Controllo Immediato.

[lucausa75]

Originariamente inviato da MarcoGG

Ti stai ponendo problemi strani. Ma posso anche capire, visto che sei "traviato" da VB6. In VB 2010, e in generale in VB.NET post-VB6, devi per forza accettare il fatto che stai usando un linguaggio al 100% OO.

Perchè dovresti cancellare quelle righe, non l'ho capito, ma qui una Form è una Classe, che eredita da System.Windows.Forms.Form.

Tutto il codice che VS genera quando crei un nuovo progetto WinForms, lo devi prendere com'è e non toccarlo.

[lucausa75]

Originariamente inviato da MarcoGG

Menu Debug / Finestre / Controllo Immediato.

...mi perdo nei meandri di VB2010 ma cmq mi piace e anche tanto!

Come si traduce il vecchio App.path di VB6?

Questa è una cosa su cui ci sto sbattendo da tempo; ad esempio se con VB6 dovevo collegarmi ad un database chiamato Clienti.mdb all'interno di C:\Users\Admin\Desktop\VB\Autorun bastava usare App.path che puntava alla cartella C:\Users\Admin\Desktop\VB\Autorun ed il gioco era fatto; adesso invece vedo che la maggior parte delle istruzioni Application.Qualcosa puntano alla directory bin:



Significa che dovrei mettere il mio database dentro bin?

[GameKeeper]

Io solitamente aggiungo al progetto i file a cui devo accedere dall'applicazione in modo che poi vengano automaticamente copiati nella cartella bin\Debug o bin\Release quando compili...
Ad esempio se provi a cliccare con il tasto dx sull'icona del progetto e poi fai aggiungi elemento esistente potrai aggiungere un file. Una volta aggiunto il file al progetto potrai visualizzarne le proprietà e una di queste serve proprio a fare in modo che venga copiato durante la compilazione... Dovresti riuscirci facilmente

[lucausa75]

Originariamente inviato da GameKeeper

Io solitamente aggiungo al progetto i file a cui devo accedere dall'applicazione in modo che poi vengano automaticamente copiati nella cartella bin\Debug o bin\Release quando compili...
Ad esempio se provi a cliccare con il tasto dx sull'icona del progetto e poi fai aggiungi elemento esistente potrai aggiungere un file. Una volta aggiunto il file al progetto potrai visualizzarne le proprietà e una di queste serve proprio a fare in modo che venga copiato durante la compilazione... Dovresti riuscirci facilmente

...di grandissimo aiuto il tuo consiglio.

Quindi se ho capito bene conviene mettere inizialmente i miei file che in questo caso 3 dentro la cartella bin\Debug o bin\Release così quando li aggiungo al progetto basta puntare a una di quelle due directory a seconda di dove li ho messi.

1) Da cosa dipende la scelta di bin\Debug e bin\Release?
2) Nelle proprietà di questi file dove trovo la voce che imposti dove venga copiato durante la compilazione?
3) Come richiamo il percorso di questi file in fase di stesura di codice?
...in poche parole nel caso di bin\Debug o bin\Release la notazione corretta è: Application.XXXXX

Grazie 1000 ancora per il supporto!

[GameKeeper]

No in realtà non devi copiare i file dentro bin\Debug o bin\Release perchè, se impostato a modo, ci pensa il compilatore a farlo! Se clicchi su un file nella finestra del progetto, vedrai che appariranno le sue proprietà nell'apposita finestra (in genere in basso a destra sotto alla vista del progetto). La prima opzione se non sbagli si chiama proprio "Copia nella directory di output" o simile. Se la imposti su copia sempre, ogni volta che compili il file viene copiato nella cartella di output, se invece metti copia se più recente la copia avviene solo se il file in questione è più recente di quello già copiato nella cartella di output (ad esempio se lo modifichi poi verrà ricopiato).
bin\Debug e bin\Release sono le 2 cartelle di output: la prima viene utilizzata durante le operazioni di debug (quindi in genere quando premi il tasto "play" in visual basic) mentre la seconda conterrà i file di output utilizzabili tranquillamente senza necessità di debugger o altre cose simili ed è la cartella di output quando usi l'opzione "Compila soluzione" nel menù Debug.
Spero di essere stato chiaro, altrimenti chiedimi pure spiegazioni!

[MarcoGG]

Originariamente inviato da lucausa75

Come si traduce il vecchio App.path di VB6?

Application.StartupPath, che in fase di debug punta alla bin/Debug.
In ogni caso punterà sempre alla cartella da cui viene lanciato l'exe o per essere più precisi, dal file eseguibile in cui risiede il punto di ingresso dell'Applicazione. Dal momento che Application.StartupPath manca dll'ultimo back-slash, per poterlo usare a scopo pratico dovrai aggiungerlo :

Application.StartupPath & "\"

Originariamente inviato da lucausa75

Questa è una cosa su cui ci sto sbattendo da tempo; ad esempio se con VB6 dovevo collegarmi ad un database chiamato Clienti.mdb all'interno di C:\Users\Admin\Desktop\VB\Autorun bastava usare App.path che puntava alla cartella C:\Users\Admin\Desktop\VB\Autorun ed il gioco era fatto; adesso invece vedo che la maggior parte delle istruzioni Application.Qualcosa puntano alla directory bin:
...
Significa che dovrei mettere il mio database dentro bin?

Esatto. Se vuoi che la tua Application faccia uso di un DB Access locale, che dovrà stare sempre nella medesima directory dell'eseguibile, userai Application.StartupPath & "\" e in fase di debug metterai il file Access in bin\Debug.

E poi alcune considerazioni te le devo fare, perchè stasera sono in vena di spiegare e vedo che stai immancabilmente cadendo nella classica tentazione irresistibile di chi chiede : "In VB6 facevo così - come faccio in VB.NET ?"

Microsoft viene incontro ai bisogni del povero ex-VB6 che si sente un po' spaesato. Se vai nell'esplora soluzioni e dai un'occhiata alle proprietà del progetto ( in questo caso Progetto, NON Soluzione ), noterai che nei Riferimenti / Spazi dei nomi importati, il primo fra tutti è un certo "Microsoft.VisualBasic".
Tutto ciò è insieme un bene, e un male.
Un bene, perchè ti consente di usare praticamente il 90%, se non di più, dei costrutti tipici di VB6, garantendo a chi è pigro un passaggio abbastanza "indolore".
Un male, perchè tu, che sei agli inizi, non potrai distinguere ciò che è davvero VB.NET ( che non ha nulla a che fare con VB6, a parte una mera somiglianza sintattica ), da ciò che VB.NET tollera, se viene ancora scritto "alla-VB6".

Esempio. Voglio una MsgBox che mi informi sulla lunghezza di una stringa.

In VB.NET posso scrivere :

        Dim stringa As String = "ciao"
        MsgBox(Len(stringa))

e nessuno si incazza, ma prova a togliere il segno di spunta a Microsoft.VisualBasic dallo "Spazi dei nomi importati" e con grande sorpresa noterai che ora il debugger da errore su MsgBox e su Len, definendoli "nomi non dichiarati".

Riscrivi tutto così :

        Dim stringa As String = "ciao"
        Microsoft.VisualBasic.MsgBox(Microsoft.VisualBasic.Len(stringa))

Nessun errore.

Adesso riscrivi così :

        Dim stringa As String = "ciao"
        MessageBox.Show(stringa.Length) 

Ecco, QUESTO è il vero VB.NET.

Ti starai chiedendo : ma come ?! stringa.Length ?
Esatto. In VB6 la stringa era un tipo. In VB.NET è un oggetto.
Con tutte le conseguenze che scoprirai...

[lucausa75]

GameKeeper e MarcoGG,

ottima spiegazione: grazie di vero cuore!
Adesso tutto è più chiaro.

Questo ciò che ho impostato:







P.S. Ma avete mai pensato a scrivere una guida?
Siete molto preparati...

[MarcoGG]

Originariamente inviato da lucausa75

...
Questo ciò che ho impostato:
...

Beh sì, se a te piace così.
Ma non è affatto necessario star lì a tirarsi nel progetto tutti i files secondari di cui l'applicazione ha bisogno a runtime.
Personalmente anzi la trovo una pratica dannosa. Io nei files di progetto voglio sempre vedere solo le Classi, i Moduli, e le risorse strettamente necessarie ( al massimo tollero files di testo e icone per le Forms... ) .
In parole povere il codice sorgente.
Immagina un progetto con 100 classi, che nell'explorer sono mischiate con file immagine, video, icone, file audio,... Visivamente un macello.
Questa, almeno, è la mia filosofia.
Puoi sempre aggiungere manualmente i file di cui l'applicazione può aver biosogno, e farvi accesso dinamicamente da codice ( Application.StartupPath... ), meglio ancora se in apposite sottocartelle : \bin\Debug\icone\, bin\Debug\video\, bin\debug\suoni\, ecc... Molto più pulito e ordinato, e te ne accorgerai quando farai applicazioni più complesse.

[lucausa75]

Originariamente inviato da MarcoGG

Beh sì, se a te piace così.
Ma non è affatto necessario star lì a tirarsi nel progetto tutti i files secondari di cui l'applicazione ha bisogno a runtime.
Personalmente anzi la trovo una pratica dannosa. Io nei files di progetto voglio sempre vedere solo le Classi, i Moduli, e le risorse strettamente necessarie ( al massimo tollero files di testo e icone per le Forms... ) .
In parole povere il codice sorgente.
Immagina un progetto con 100 classi, che nell'explorer sono mischiate con file immagine, video, icone, file audio,... Visivamente un macello.
Questa, almeno, è la mia filosofia.
Puoi sempre aggiungere manualmente i file di cui l'applicazione può aver biosogno, e farvi accesso dinamicamente da codice ( Application.StartupPath... ), meglio ancora se in apposite sottocartelle : \bin\Debug\icone\, bin\Debug\video\, bin\debug\suoni\, ecc... Molto più pulito e ordinato, e te ne accorgerai quando farai applicazioni più complesse.

OK condivido il tuo punto di vista ma adesso dopo che ho messo i miei file dentro bin\Debug è normale che mi ritrovo i files nella cartella principale oltre che dentro bin\Debug e bin\Release (se seleziono l'opzione "COPY IF NEWER")?



E' normale che come full path dei singoli file trovo questo?



Grazie e perdonami per la valanga di domande a cui stai dando sempre risposte chiare