Newsgroup: it.comp.lang.visual-basic
Titolo: Passaggio di variabili

Salve a tutti. Ho un problemino. In un mio programma devo usare delle
variabili (dichiarate in un certo form) in più form. Posso fare a meno di
usare i moduli? Se non posso essi come si usano? Grazie





 usare i moduli? Se non posso essi come si usano? Grazie
Se proprio non vuoi usare i moduli (ti basta fare inserisci modulo), nella
sezione dichiarazioni della form "padre" dichiara le tue variabili come
Public e nelle altre form riferisciti alle stesse con
Nome_Form_Padre.nome_variabile

E' giusto quel che ti ha detto Wolf... perň io direi che l'utilizzo di un
modulo č una soluzione piů elegante.
Chi non č d'accordo?
Antonio

 Nome_Form_Padre.nome_variabile
Ciao Lupo!
A questo proposito posso chiederti perche' sul NG tanti guru sconsigliano
l'uso di variabili public in un modulo? In un mio progetto ho una marea di
variabili public dichiarate in un modulo apposito (tieni presente che le
devo usare in piu' form).
Quali sono le controindicazioni? E quali le maniere per evitare che
succedano problemi (che, tra l'altro, a me non si sono mai verificati,
almeno fin'ora - e qui vado con una grattatona ai gioielli di famiglia!)?
Grazie per l'attenzione (domanda rivolta a tutti)!
- SonicBoom -

 l'uso di variabili public in un modulo?
Le variabili pubbliche fanno perdere portabilità al codice. Cioè, se vuoi
riutilizzare del codice che hai scritto per un'altra applicazione, devi
ricordarti di portarti dietro anche le variabili pubbliche, e c'è la seppur
remota possibilità che nel nuovo progetto una variabile con quel nome esista
già e crei dei problemi.
Si tratta solo di una questione di pulizia del codice. Quando possibile, è
meglio usare variabili locali, oppure proprietà. Se ciò non è possibile e
devi usare delle variabili pubbliche, per lo meno dove possibile raggruppale
per tipologia sotto un unico Type.
Ad esempio le variabili in cui salvi i dati dell'utente della tua
applicazione potrebbero stare in una Type Utente, in cui salvare
GtUtente.sUserName, GtUtente.sPassword, etc.
Alcuni sconsigliano anche l'uso di variabili pubbliche a livello di form, e
caldeggiano invece l'uso di proprietà. Anche qui si tratta di gusti. Se c'è
la minima possibilità che in un futuro al variare della variabile di Form
debba avvenire qualche cosa, è meglio usare una proprietà, altrimenti va
bene anche una normale variabile Public.
Ciao
*Roby*

 ha scritto nel messaggio
news:ZfMK8.13108$QT3.3...@twister2.libero.it...

Ti ha già risposto Roby. Ne uso tante anch'io (solo nei moduli), ma non
dirlo a nessuno. ;-)

> Le variabili pubbliche fanno perdere portabilità al codice.
[CUT]
Esaustivo come sempre, mille grazie!
Nel mio progetto ho una serie di variabili pubbliche impostate come
Public Type Qualcosa
e, come avevo detto in precedenza, ho riportato tutte le dichiarazioni di
tipi di variabili, le variabili pubbliche e le costanti in un modulo a parte
che, all'occorrenza, ricopio in un altro progetto.
A parte la portabilita', dunque, mi pare di capire che altri problemi
"macroscopici" non ve ne siano. O sbaglio?
Grazie ancora, comunque!
- SonicBoom -

 dirlo a nessuno. ;-)
Muto sto! :)
Comunque leggi anche la mia risposta a Roby e, se hai dei consigli
particolari, non esitare a darmeli! :)
- SonicBoom -

 "macroscopici" non ve ne siano. O sbaglio?
Sbagli :)
Il problema principale non credo sia la portabilitą (direi piuttosto
"riusabilitą", importante anche lei) ma il fatto che se uso una var devo
sapere da dove arriva.
Questo non accade con le variabili "globali".
Poi non si riesce a capire se la variabile che uso č locale al modulo o
globale per l'app.
Se ne ho una locale (di cui ignoro o non ricordo l'esistenza) rischio di
usare quella globale per errore.
Insomma, troppi rischi.
Comunque, per tagliare corto, hai presente java (il linguaggio)?
Quello che č stato proclamato il linguaggio meglio strutturato che
impedisce, anche volendolo, di scrivere codice "spaghettaro"?
Beh, i moduli non sa neanche cosa siano.
C# lo stesso.
VB.NET
 con qualche acrobazia riesce a usarli ancora ma solo per
compatibilitą.
Delphi li lascia usare ma con molte restrizioni (visti rispetto a VB).
Un motivo ci sarą :P
Ciao

 usare quella globale per errore.
Ok, passo all'esempio pratico:
io leggo dei file di dati, pongo tali dati (numeri) in un type che e'
strutturato (piu' o meno) cosi':
Type Dato
    Dn As Long
    Tz As Double
    Tn As Double
    Te As Double
    Zz As Double
    Ns As Double
    Ew As Double
End Type
dopodiche' dichiaro public
Public Dati() as Dato
e tante altre belle cosine.
Nel form principale faccio un tipo di analisi, in un altro form un altro
tipo di analisi (sempre sugli stessi dati), etc. Inoltre calcolo medie,
varianze, covarianze, fft, etc. in funzioni che ho scritto in un altro
modulo, analisi che avviene sempre sugli stessi dati. Io _SO_ questi dati da
dove vengono (li ho letti una volta e amen), e so anche cosa ci devo fare...
Insomma: che vantaggio avrei (_SE_ ne avessi...) a dichiarare in frmMain
questi dati, anziche' in un modulo? (spero di non approfittare della tua -
checche' ne dicano "altri" - cortesia)
Mille grazie!
- SonicBoom -

 Grazie per l'attenzione (domanda rivolta a tutti)!
--
Ciao.
Maurizio
--------
?SPQR(C)
 X
--------

 Public Dati() as Dato
Ecco, il tuo esempio è esattamente il tipo di struttura/variabile che può
causare problemi.perchè le tue variabili non hanno un nome "parlante".
Dal nome della variabile infatti non si capisce se questa è locale alla
funzione, al mudulo, o globale.
Personalmente uso dei prefissi per gestire queste tipo di differenziazione:
"GLO_" per le variabili globali, "GM_" per le globali a livello di modulo, e
nulla per le variabili locali alla funzione. C'è anche chi usa un prefisso
per differenziare i parametri di funzioni dalle variabili locali, ma di
solito questo non serve se dichiari correttamente ByVal tutte le variabili
che usi come parametri delle funzioni.
A parte questi prefissi che definiscono la visibilità delle variabili, ce ne
sono altri che ne definiscono il tipo. Ad esempio una globale di modulo di
tipo stringa che definisce il nome del file di input dovrà chiamarsi
GM_sNomeFileInput e non NF. In questo modo ti basterà una singola occhiata
per sapere esattamente la tua variabile a cosa serve. "GM" stabilisce che è
globale di modulo, "s" che è doi tipo stringa, e "NomeFileInput" è un nome
che dovrebbe chiarirne il contenuto.
Anche i nome delle Sub e delle Funzioni dovrebbero essere il più verbose
possibili, e seguire degli standard. Ad esempio le funzioni che ritornano
valori booleani sarebbe meglio avessero un prefisso di tipo "Is" (tipo che
se la funzione ritorna l'esistenza o meno di un file, potrebbe chiamarsi
"IsFile").
Esiste un bel documento sul Sito Comune che ha scritto Zanna e che spiega
quali sono i prefissi corretti da utilizzare. Probabilmente sono diversi da
quelli che uso io, ma sono sicuramente più standard. Da buon autodidatta, i
miei prefissi me li ero inventati man mano che lavoravo, e adesso faccio
fatica a cambiare per adeguarmi agli standard, ma se parti già col piede
giusto è meglio.
Io uso un'altra regola per il mio codice: dove possibile usare variabili e
nomi di funzioni e Sub in italiano. Questo rende semplice vedere subito
quale è codice che ho scritto io, e quali sono istruzioni VB o di controlli
di terze parti. Però anche questa è una questione soggettiva, e altri
preferiscono usare l'inglese.
In ogni caso, evita di usare variabili di 2 lettere. Della tua struttura io
non capisco nulla, e non ci sono neppure commenti esplicativi.
Anche se ci fossero, i commenti sono comunque più scomodi di un buon nome
parlante, che rende più leggibile il codice. All'inizio ti sembra di perdere
tempo a scrivere nomi troppo lunghi, ma dopo un po' ti verrà spontaneo, e
quasi sempre puoi sfruttare l'autocompletamente dopo aver premuto pochi
tasti.
Per chiudere volevo solo dire che se usi la corretta nomenclatura, puoi
anche permetterti di usare le variabili globali perchè non c'è più il
rischio di usare lo stesso nome per due variabili con visibilità diversa.
Resta solo il problema della portabilità del codice, ma quello alla fine è
in molti casi secondario.
Ciao
*Roby*

 ha scritto nel messaggio
news:adgjrm$10p4tm$1...@ID-94194.news.dfncis.de...

Roby, premetto e sottolineo che hai assolutamente e totalmente ragione.
Ma, mentre ti leggevo, mi son venuti in mente due scrittori:
Il primo (tu) ha il tempo per scrivere un romanzo.
Il secondo (io) ha solo il tempo di scrivere un racconto.
Ovvio che sia il romanzo che il racconto sono buoni, gradevoli e
"vendibili".
Hanno, insomma, gli stessi _identici_ contenuti e potenzialità.
Certamente, sono il primo a dirlo, tenere in mano un romanzo dà una
sensazione diversa di quella che si può avere tenendo in mano un racconto,
ma, troppo spesso, non si ha il tempo di scrivere ... più di quanto sia
davvero necessario.

 Il secondo (io) ha solo il tempo di scrivere un racconto.
Circa sei anni fa, in occasione della migrazione da 16 a 32 bit di un grosso
prodotto in VB4, ho fatto un investimento in tempo e mi sono riscritto tutto
le rountine di base uniformandole ai miei standard attuali.
Da allora i miei problemi di programmazione sono diminuiti di molto, e mi
sono ripromesso di scrivere sempre e solo codice autoesplicativo.
Mi ricordo che prima mi capitava di dover riprendere in mano dei programmi
scritti magari due anni prima e non capirci un bel niente. Erano magari
pieni di commenti, ma i commenti stavano vicino alle dichiarazioni delle
variabili, o delle funzioni, e non all'interno del codice in ogni riga.
Se scrivi codice autoesplicativo, puoi risparmiarti i commenti quasi del
tutto, e il tuo programma resta comunque leggibile negli anni.
Ci sono un paio di trucchi per velocizzare il tutto. Il primo è lavorare
sempre col CapsLock premuto. Mentre scrivi, se sbagli a scrivere qualcosa,
il testo resterà in maiuscolo e te ne accorgerai subito. In caso contrario
diventerà minuscolo e sarà segno che va tutto bene.
Il secondo è usare l'autocompletamente quanto più sia possibile. Premi
Crtl-Spazio dopo 2 o 3 lettere, e ci pensa VB a terminare per te il nome
della variabile o della funzione, o a proporti tutte le scelte possibili..
Secondo me alla fine il tempo che impieghi è addirittura inferiore. Però
ovviamente ognuno è libero di fare come preferisce e se nel codice ci devi
mettere le mani solo tu, l'importante è che sia scritto in modo che ci
capisci tu.
Se però domani ti si amplia l'attività, devi pensare anche a quei poveri
disgraziati dei tuoi futuri collaboratori. :-)
Ciao
*Roby*

 disgraziati dei tuoi futuri collaboratori. :-)
Futuri collaboratori? No, e non per cattiveria...
L'attività vorrei ridurla, ebbene sì, in termini di vivibilità.
Non serve a niente fare più di quanto serve, anzi...
Ciao.

 Il secondo (io) ha solo il tempo di scrivere un racconto.
Questo è un discorso puramente commerciale che alla lunga non paga.
Ti serve per stare nei tempi di consegna, ma poi ci perdi (o ci guadagni
molto meno) nelle succeccive rivisitazioni/correzioni (di errori fatti per
stare nei tempi :))
Ciao

 stare nei tempi :))
Hai (potenzialmente) ragione, ma io avevo anche scritto


 funzione, al mudulo, o globale.
Mille grazie per le delucidazioni, puntuali e preziosissime.
Voglio pero' spezzare una lancia in mio favore! :)
Tu dici che dalla struttura non si capisce una cippa, pero' per me e'
chiarissima! :) Intendo dire: ho dei dati numerici che rappresentano una
coordinata Nord/Sud (Ns), una Est/Ovest (Est/West, Ew) ed una quota (Zz),
dei tempi d'arrivo per ciascuna di esse (T(empo d'arrivo)n(ord/sud), etc.),
ed un identificatore univoco, Dn (Dato Numero). Credo che queste cosine qui
non debbano necessariamente essere piu' descrittive di quanto non siano, o
no?
Poi magari differenzio in maniera migliore il nome dei vari array (infatti
ho nomi meravigliosi, tipo "DatiReali", "DatiImmagine", "ComponentiRuotate",
"ComponentiRuotateImmagine", "FattoreMoltiplicativo", etc.).
Last, but not least: il mio programma non verra' mai venduto! Lo sto
scrivendo per la mia tesi e non credo proprio che cedero' tanto facilmente i
sorgenti (a meno che la mia relatrice non mi sevizi...)!! :)
Ribadisco: se l'unico problema conclamato e' la leggibilita' del codice (ora
pero' vado a rispondere anche a Maurizio Borrelli!), non credo mi convenga
modificare tutto l'applicativo (anche se, mi rendo conto, potrei usare un
"Sostituisci...", e via!).
Sicuramente, comunque, terro' in debita considerazione le vostre indicazioni
per i futuri progetti che sviluppero' (volesse il Cielo...).
Ciao,
- SonicBoom -

 di tela senza niente da metterci dentro.
Spero proprio di no! :) Anche perche' non vorrei che 4 milioni di persone si
trovassero in mezzo alla strada per colpa di una variabile pubblica... :)
(questa l'ha capita solo Roby)
In ogni caso, mille grazie!
- SonicBoom -

 Roby, premetto e sottolineo che hai assolutamente e totalmente ragione.
Lupo, premetto e sottolineo che ti voglio bene.
...ma un po', dico, _un pochino_ di quoting, per favore ? :-)))
Grazie, G.

 diventerà minuscolo e sarà segno che va tutto bene.
Guarda che strano... io faccio esattamente il contrario, per
lo stesso scopo. Le dichiarazioni sono del tipo
Dim strTestoDainviare As String
e se quando batto c'è qualche errore, rimane tutto minuscolo...
Un Paperino e l'abitudine a non URLARE ;-).

 di tela senza niente da metterci dentro.
BI-LOL
Bye, G.

 sorgenti (a meno che la mia relatrice non mi sevizi...)!! :)
da quando demi e' associata ?

 (questa l'ha capita solo Roby)
sarebbe forse peggio se 4 mln di persone si ritrovassero senza niente da
grattare...

 da quando demi e' associata ?
Erm... non credo di averla capita, questa!
- SonicBoom -

 grattare...
Potrebbe essere un problema anche questo, effettivamente!
- SonicBoom -

 ha scritto

strano. molti uomini hanno sognato di essere seviziati da demi moore...

 strano. molti uomini hanno sognato di essere seviziati da demi moore...
^____^
eheheh!
Onestamente non e' un granche' come docente, ma per il resto... :)
- SonicBoom -

 Eheheheh!!! Questa e' davvero una battuta di *classe*! :)
    Beh, ricorderai certamente il catechismo di Applemann:
    What Is a Window?
    Windows Have Class
    Windows Have Style
[...]


 Un Paperino e l'abitudine a non URLARE ;-).
Anche a me da fastidio, infatti è proprio quello il motivo per cui me ne
accorgo subito se restano in maiuscolo. Lo standard suggerirebbe che le
costanti debbano essere scritte in maiuscolo, ma anche quello mi da fastidio
e mi limito a farle precedere da K_ o KG_ e mantenere il capitalizzato come
nelle variabili normali.
Ciao
*Roby*

 ...ma un po', dico, _un pochino_ di quoting, per favore ? :-)))
Ciao grande papero, hai ragione. Pardon

 maiuscolo, che si tratta di un errore salta subito agli occhi
...mi sa che ci proverò anch'io :-)
TNX, G.