Newsgroup: it.comp.lang.visual-basic
Titolo: VB6   una curiosità sulle variabili

Buon anno a tutti.
 
Immaginiamo una variabile definita pubblica in un modulo
ed una variabile con lo stesso nome in un form.
 
Operando all'interno del form c'è modo di conoscere il
valore della variabile pubblica?
 
Sauro 
 
 


<NomeModulo>.<NomeVariabile>
 
Bye by SixaM 8-]

 Bye by SixaM 8-]
 
Elementare!
 
Grazie SixaM
Sauro 
 
 

Il 14/01/18 19:58, Sauro ha scritto:

Mi permetto di sollevare una obiezione sull'opportunità di utilizzare 
variabili con lo stesso nome che non mi sembra molto ortodosso neanche 
dal punto di vista dell'ordine...in fin dei conti non è che manchi la 
possibilità di trasferire un valore da una variabile ad un'altra! E 
penso non manchi nemmeno la fantasia sui nomi! :)

 penso non manchi nemmeno la fantasia sui nomi! :)
 
Senz'altro vero; d'altra parte può succedere, nell'ambito di applicazioni un po' complesse, di dover incorporare moduli di codice condivisi in progetti diversi, e in quel caso e' bene sapere come risolvere queste ambiguita' senza essere costretti a modifiche sui sorgenti.

 un'altra! E penso non manchi nemmeno la fantasia sui nomi! :)
 
Mi permetto di dissentire sull'ultimo punto :-(
 
Ogni volta che in qualche programma altrui mi imbatto in
una variabile battezzata con /quasi/ lo stesso nome del
suo tipo, o cinque oggetti chiamati Object1...Object5
che potrebbero essere letteralmente qualunque cosa,
o magari con un nome che sembra, ma non è, un nome di
oggetto, m'incazzo alquanto.
 
E quelli che lasciano i nomi di default agli oggetti?
Un gruppo di pulsanti che si chiamano Button1, Button2,
Button3, Button4 proprio non si può vedere.
Se li rinomini, e ci vogliono 5 secondi netti quando li
crei, in un qualunque punto del codice li incontri
btnStampa, btnVisualizza, btnMostra e btnNascondi ti
dicono già chiaramente a cosa servono nel contesto del
programma, senza che tu stesso debba andare a ripescare
il codice quando riapri il programma dopo una settimana.
 
E le dichiarazioni come "e As Sender" oppure il mostruoso
"ByVal e As System.Windows.Forms.DragEventArgs" ?
Ma perché "e" invece di qualcosa di più significativo?
Basterebbe un drag_events_arguments per chi vuole gli
underscore, o DragEventsArguments per chi preferisce il
CamelCase, o un quel che vi pare, ma "e" non ha senso.
 
Un'altro guaio è che c'è gente che programma a forza
di copia e incolla da StackOverflow o CodeProject; e non
è niente di male né sbagliato; e chi più chi meno lo
facciamo tutti.
E' come far pipì sotto la doccia: chi nega di farlo
mente >:-] e mente senza motivo di farlo.
Ma cazzarola, almeno cambia i nomi delle variabili: cosa
cappero ci si capisce nel tuo codice se "e" significa
tredici cose diverse in cinque sub e otto function?
 
Una volta ho incontrato un'altra cosa che ho cercato di
dimenticare - e ci sono riuscito :-D - era qualcosa come:
Dim Data as Data.FindData.Data.toDate (ovviamente non era
così, che non avrebbe senso :-D, ma ci andava vicino).
 
...ed è in questi casi che mi chiedo "ma un po' di fantasia,
proprio no?"
 
 
 
*****************
Scusate il RANT, ma è una cosa che mi stava sullo stomaco
da un po', e oggi il caffè era un po' troppo forte :-)
 
 
Bye, G.

 da un po', e oggi il caffè era un po' troppo forte :-)
 
sfogo condivisibilissimo, "mi sono letto" parola per parola, comunque
non e' infrequente creare UN modulo/oggetto/sarcazzo e quindi
crearne piu istanze, diviene (quasi) l'unico modo gestirne le variabili
come nomeoggetto(x).nomevariabile, quindi e' intrinseco che esistano 
piu
variabili con nome identico, sono comunque d'accordo sulla poca
scaltrezza nel "riciclare un nome di variabile quando non e' 
un'esigenza.

 CamelCase, o un quel che vi pare, ma "e" non ha senso.
 
Su questo esempio specifico, la vedo tutta al contrario... personalmente sono più che contento che il codice auto-generato degli eventi di .NET usi sempre 'sender' ed 'e' come nomi parametri
 
A parte il fatto che rappresentano effettivamente sempre la stessa cosa (sendere è sempre l'oggetto chiamante, 'e' deriva sempre da EventArgs base, di qualunque sottotipo sia), in quel modo riconosci a colpo d'occhio che sei in un gestore evento, utile in particolare quando magari aggiungi l'handler dinamicamente invece che in design, e quindi ti viene elencato insieme alle funzioni normali nel combo a destra invece che a sinistra; in più è anche decisamente più semplice riutilizzare il codice da uno all'altro con l'uniformità dei nomi.... nota che sono nomi non usati in nessun altro contesto che quello, perchè tutte le altre parti in cui Visual Studio auto-genera codice, usa nomi differenti.
 
Poi in genere sono variabili fatte apposta per prendere il valore che ti serve ad inizio evento e dimenticarsele, quindi è veramente difficile che uno si confonda e abbia bisogno di nomi più significativi.