Newsgroup: it.comp.lang.visual-basic
Titolo: R: ? variabile pubblica

pubblica, ma solo per tutte le sub di quel form.
Ma che dici?
Un form essendo un oggetto deve errese referenziato:
Da form2:
    Caption = Form1.Pippo
Una var. pubblica è pubblica, in tutto il progetto (altrimenti sarebbe
private, per cui diventerebbe "pubblica" per le sole sub del
modulo/form/classe).
Ciao

 wrote in message 8pr1jv$48h$1...@nslave1.tin.it...


scusami, ma credo che tu sia in errore: non si parlava delle proprietà
degli
oggetti, ma di variabili...
 
______________________________________________________________________________
Vous avez un site perso ?
2 millions de francs à gagner sur i(france) !
Webmasters : ZE CONCOURS ! 
http://www.ifrance.com/_reloc/concours.emailif
--
Posted from 
lh00.opsion.fr
 [212.73.208.226] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 wrote in message
000701c01ee0$9e637680$266ad2c3@a4q0o0...


Se, invece, abbiamo un form MDI che richiama prima il Form1, poi lo scarica
e richiama il Form2, non otterremmo il risultato voluto.
 
______________________________________________________________________________


direttamente, del tipo Form1.LeggiVariabile("NomeVariabile")
3) Implementare delle routine Property Let/Get: il risultato è lo stesso del punto 1), solo che è
più elegante e non lascia spazio a dubbi...
Ciao,
Moreno
#sirri#@#morenosoft#.com
(togliete "#" dall'indirizzo)
Moreno Sirri VB Site - 
http://www.morenosoft.com/MSVBSite/
---------------------------------------------------------------------------
Le risposte alle tue domande le trovi sul Sito Comune di questo NewsGroup:
 
http://www.murialdo.it/it_lang_vb
---------------------------------------------------------------------------

 e richiama il Form2, non otterremmo il risultato voluto.
Ciao Ettore,
proprio perchè non si finisce mai di imparare, devo obbiettare a questa tua
ipotesi.
Abbiamo appurato non troppi giorni fa che che le variabili pubbliche di un
form non sono in alcun modo legate al suo caricamento in memoria: il primo
riferimento esplicito al form alloca le sue variabili pubbliche e le
inizializza provocando solo l'evento _initialize_ del form, queste cmq
mantengono il loro valore anche dopo che il form è stato scaricato e
continuano ad essere accessibili senza provocarne alcun caricamento.
Ergo, sono praticamente identice alle variabili pubbliche di un modulo, con
il vantaggio/svantaggio di essere referenziate al form proprietario.
Ciao.
--
Princi, 
princ...@programmer.net
--------------------------------------------------------------------------
"Tutti sanno che una cosa è impossibile da realizzare,
finché arriva uno sprovveduto che non lo sa e la inventa." A.E.

il vantaggio/svantaggio di essere referenziate al form proprietario.
Io continuo a sostenere che questo sistema sia molto pericoloso: non è
facilmente intuibile che "si è fatto così _solo_ perchè così funziona".
Inoltre usare var. in un oggetto che hanno valenza per il progetto anzichè
per il solo oggetto è sintomo di una malprogettazione dell'applicativo.
Ciao

 il vantaggio/svantaggio di essere referenziate al form proprietario.
a questo punto pero', anche a proposito degli stili di programmazione, non
capisco proprio perche' uno non se le tenga tutte, possibilmente vicine, in
bel modulo, dove le trova subito (lui e specialmente un altro che guardi il
codice). mi sfugge l'aspetto vantaggioso di questa soluzione.
ciao, a.

 per il solo oggetto è sintomo di una malprogettazione dell'applicativo.
Giusto. Ma prima ancora dell'applicativo è sintomo di una mal progettazione
del linguaggio VB.
Il form è un'oggetto molto particolare, possiamo forse dire per estremo che
viene istanziato in fase di progettazione (passatemela così com'è perché se
no non ne veniamo fuori più).
Il VB tratta sia le variabili pubbliche dei form che le funzioni pubbliche
degli stessi esattamente come variabili e funzioni "statiche" (questo è il
motivo percui non perdono il loro valore), ma hanno cmq valenza per
l'oggetto e non per il progetto. In effetti dal punto di vista teorico non
sono uguali alle variabili pubbliche di un modulo, le prime esistono solo se
l'oggetto è stato istanziato. Il problema nasce dal fatto che il VB lo
istanzia implicitamente al primo riferimento all'oggetto, ma ne alloca solo
la memoria dedicata a variabili e routine, rimandando il caricamento della
componente visuale ed di tutti i controlli figli all'istruzione di load.
Quando lo scarico, lo scarico veramente, ma al prossimo riferimento ad una
var o ad una function il VB me lo ricarica ed io mi ritrovo i miei valori
perchè le variabili del form sono statiche.
Chiarito il meccanismo, rimango anch'io dell'idea che usare questa
particolarità del VB con troppa disinvoltura sia abbastanza pericoloso e
forse anche dispendioso in termini di risorse. Sicuramente il codice che ne
risulta potrebbe non essere molto chiaro per chi non sa come "ragiona" VB.
Ciò non toglie che a volte può cmq essere molto utile poter avere tante
variabili con lo stesso nome e la stessa funzionalità ognuna riferita ad un
form diverso piuttosto che avere tante variabili con diversi nomi tutte
infilate in un modulo (è anche questione di manutenibilità: se un form è
autosufficiente posso permettermi di aggiungerlo o sostituirlo ad un altro
senza dovermi preoccupare di creare variabili globali di appoggio).
P.S. l'implementazione di funzioni getvar/setvar sono soggette allo stesso
meccanismo e quindi soffrono delle stesse "malattie"; il loro utilizzo è
valido anche se il form non è caricato perché viene sempre istanziato
implicitamente.


 codice). mi sfugge l'aspetto vantaggioso di questa soluzione.
Appunto, stili personali di programmazione. Io le variabili globali le odio
e cerco di usarle solo se indispensabili. Questo per avere il più possibile
blocchi di programma autosufficienti che non abbiano dipendenze esterne.
Ho postato cmq una più completa risposta a Zanna, ti invito a leggerla anche
in riferimento alla tua obbiezione.
Ciao.


 più elegante e non lascia spazio a dubbi...
come funzionano?
ma non servono a creare le proprietà per i controlli ocx?

no non ne veniamo fuori più).
Ok :)
D'accordo anche con quanto seguiva.
Una nota: io per evitare questo problema della "staticità" (che stranamente
ho riscontrato in modo un po' aleatorio) uso sempre un bel
Unload Form1
Set Form1 = Nothing
Così VB è costretto a scaricarsi tutto il codice fi Form1 e la mia
condizione è sicuramente pulita (come dovrebbe essere).
ciao

...

Tutte le classi le possono avere (OCX, Class, Form...).
Funxionano così:
dichiari una var privata a livello di modulo (con modulo intendo modulo di
classe)
Private v as QuelloCheVuoi
Private o as TipoOggetto
' Imposta la proprietà
Public Property Let MyProp([ByVal Params... ,]ByVal NewValue As
QuelloCheVuoi)
    v = NewValue
    ' Qui ci fai quello che vuoi
End Property
' Imposta la proprietà di tipo oggetto
Public Property Set MyProp([ByVal Params... ,]ByVal NewValue As TipoOggetto)
    o = NewValue
    ' Qui ci fai quello che vuoi
End Property
' Legge la proprietà
Public Property Get MyProp([ByVal Params... ,]) As QuelloCheVuoi
    ' Qui ci fai quello che vuoi
    MyProp = v
End Property
In linea di massima se ti serve solo scrivere _E_ leggere una proprietà
conviene usare una var pubblica: è molto più semplice.
Se devi fare anche delle operazioni una volta impostata/letta una proprietà
(Es. proprietà Enabled) o solo leggere o solo scrivere devi per forza usare
le property.
Ciao

 a questo punto pero', anche a proposito degli stili di
programmazione, non capisco proprio perche' uno non se le
tenga tutte, possibilmente vicine, in bel modulo, dove le
trova subito (lui e specialmente un altro che guardi il
codice). mi sfugge l'aspetto vantaggioso di questa
soluzione.
Come dico in altro mio post in questo stesso thead, bisogna
distinguere. Bisogna distinguere in base alla *funzione* di
tali variabili. Per alcune, realmente *globali*, puo` valere
il tuo discorso, ma allora io non sarei d'accordo sul loro
uso; per altre, che potremmo definire "locali a visibilita`
pubblica" il vantaggio ce lo vedo in quanto, come ricorda
Princi, non si avrebbe l'effetto collaterale del caricamento
del form. Altro scopo ancora avrebbero le proprieta` vere e
proprie.
--
Ciao.
Maurizio
--------
?SPQR(C)
 X

 Inoltre usare var. in un oggetto che hanno valenza per il
progetto anzichč per il solo oggetto č sintomo di una
malprogettazione dell'applicativo.
In linea di massima potrei anche essere d'accordo ma...
bisognerebbe distinguere. Princi si riferisce ad un thread in
cui si discuteva a proposito del caricamento e scaricamento
dei form ed un esempio proposto come "possibile" era appunto
quello della variabile pubblica usata come flag. In quel caso
"intuibilita`", funzione ed efficiente sfruttamento delle
caratteristiche del linguaggio producevano un mix che
portavano a dire: "perche' no?...". L'insieme dava anche una
sensazione di "buona progettazione", secondo me.


 > Xaero:

Prova anche questo, Zanna... ;-)
' Modulo1
'
Option Explicit
Public Sub Main()
  Prop = "Pippo"
  MsgBox Prop
End Sub
' Modulo2; N.B.: .BAS no .CLS
'
Option Explicit
Private m_Prop
Public Property Get Prop()
  Prop = m_Prop
End Property
Public Property Let Prop(ByVal NewProp)
  m_Prop = NewProp
End Property
