-
Articoli
-
Sono d'accordo con te, anche se io, piuttosto di una variabile pubblica (capita che si "perdano"), preferisco affidarmi ad un named range.
Si', lo trovo anche piu' raffinato. Ma io sono un po' antico da questo punto di vista
Ciao a tutti,
quando avevo visto il post iniziale avevo pensato anche io ad una variabile pubbliac, poi ho fatto un po' di prove e in effetti ho avuto qualche problema...A volte non era più valorizzata...Quindi ripensando a vecchi post avevo pensato alla soluzione di scossa usando un "named Range".
Avrei soltanto una domanda per scossa:
perche farglielo aggiungere ad ogni Apertura di Workbook?
Private Sub Workbook_Open() Me.Names.Add "bShowUF", RefersTo:=True End Subperche farglielo aggiungere ad ogni Apertura di Workbook?
giusta osservazione: in realtà, se il name esiste, il metodo .Add non "aggiunge" un nuovo name ma si limita a "sostituirlo" (*).
Il motivo per cui l'ho usato è semplicemente perché non puoi essere certo del valore salvato alla chiusura quindi, all'apertura, devi impostarlo comunque a True (quindi avrei dovuto comunque usare
Me.Names("bShowUF").RefersTo:=True); considerato che la soluzione andava applicata ad un file già esistente, mi sono risparmiato di scrivere la solita pappardella di come creare il name ("propedeutica al funzionamento è la creazione di un name ......").(*) per la precisione il name viene eliminato e ricreato, ma alla fine in questo contesto (evento Open), la differenza in termini di "costo macchina" è irrisoria.
quando avevo visto il post iniziale avevo pensato anche io ad una variabile pubbliac, poi ho fatto un po' di prove e in effetti ho avuto qualche problema...
forse questa è la spiegazione? questa la fonte:
Public module-level scope
If you declare a module-level variable as public, it's available to all procedures in the project. In the following example, the string variable can be used by any procedure in any module in the project.VBCopy
' Include in Declarations section of module.
Public strMsg As StringAll procedures are public by default, except for event procedures. When Visual Basic creates an event procedure, the Private keyword is automatically inserted before the procedure declaration. For all other procedures, you must explicitly declare the procedure with the Private keyword if you don't want it to be public.
Use public procedures, variables, and constants defined in standard modules or class modules from referencing projects. However, you must first set a reference to the project in which they are defined.
Public procedures, variables, and constants defined in other than standard or class modules, such as form modules or report modules, are not available to referencing projects, because these modules are private to the project in which they reside.
Grazie a tutti per le delucidazioni
forse questa è la spiegazione? questa la fonte:
non direi: spiega solo ambito e visibilità delle variabili (/costanti/procedure) pubbliche; non trovo traccia del fatto che possano, a volte, esssere affette da "demenza senile".
a volte, esssere affette da "demenza senile".
Non ho seguito bene il discorso delle variabili pubbliche, in questa discussione, però non mi mai capitato che una variabile dimenticasse il suo stato (demenza senile). Che mi sono perso?
però non mi mai capitato che una variabile dimenticasse il suo stato (demenza senile). Che mi sono perso?
a me è capitato (e da quel che leggo non solo a me) che le variabili pubbliche, specie in file con codici complessi, non siano così "sicure" oppure, pur essendolo, vengano "involontariamente" variate, ad esempio essendo passate byRef (default) anziché byVal ad una sub/function.
Capisco
opto più per la seconda. Public procedures, variables, and constants defined in other than standard or class modules, such as form modules or report modules, are not available to referencing projects, because these modules are private to the project in which they reside.
chiedo lumi e conferme:
mi riferivo a quanto sopra, il mio inglese è quello che è, ma per quel capisco...
una variabile pubblica dichiarata tale in un modulo diverso da standard o di classe
e quindi di Evento,
non può essere richiamata da routines in moduli standard o di UserForm.
Ho capito bene?
una variabile pubblica dichiarata tale in un modulo diverso da standard o di classe
e quindi di Evento,
non può essere richiamata da routines in moduli standard o di UserForm.
Ho capito bene?
Hai capito benissimo, ma qui stiamo discutendo di variabili public dichiarate (chiaramente) in un modulo standard, infatti "normalmente" funzionano, poi ad un certo punto, specie se dichiarate as Variant "si perdono" (perché vengano "involontariamente" variate, ad esempio essendo passate byRef (default) anziché byVal ad una sub/function) .
Prova il seguente codice (inserito in un modulo standard):
Public vMyVar As Variant Sub prova() vMyVar = 6 MsgBox fMyFunc(vMyVar) & vbTab & "vMyVar: " & vMyVar MsgBox fMyFunc2(vMyVar) & vbTab & "vMyVar: " & vMyVar MsgBox fMyFunc3(vMyVar) & vbTab & "vMyVar: " & vMyVar End Sub Function fMyFunc(vVar) fMyFunc = vVar * 2 End Function Function fMyFunc2(vVar) vVar = 12 + vVar fMyFunc2 = vVar End Function Function fMyFunc3(vVar) fMyFunc3 = vVar * 2 Set vVar = Nothing End FunctionUna variabile pubblica per definizione è visibile in tutto il progetto (parlo di programmazione). Detto questo, metto le mani avanti perché non ho mai usato una variabile pubblica nel modulo di un foglio di lavoro su Excel ma solo su moduli STD o su moduli di Form. Lascia stare le variabili pubbliche su moduli di classe perché per me sono da bandire, le variabili in una classe (oggetto) vanno TUTTE incapsulate perché queste diventano gli attributi/proprietà dell'oggetto che verrà istanziato.
E' ben brutto che una variabile pubblica in un modulo standard si perda... sostituiamo tutte queste variabili con terne Property Get/Let/Set?
Hai capito benissimo
grazie per il gentile riscontro. Appena ho tempo testerò la tua proposta/verifica.
Grazie
Login
Registrati
