Newsgroup: it.comp.lang.visual-basic
Titolo: Variabili Pubbliche

Ciao ragazzi,
Volevo sapere una cosa se io inserisco una variabile X pubblica nel form
principale e gli do il valore di 4.
Ora, e la domanda è questa, posso io richiamare quella variabile X = 4 in un
form secondario tipo una finestra di dialogo?
Se no come posso fare per portarmi dietro un valore da una form ad un altro?
Ciao ciao

[SuperMarcoski]

La variabile pubblica la richiami con NomeFormPrincipale.X.
In alternativa (migliore dal punto di vista progettuale) puoi
dichiararla pubblica in un modulo (.bas). In tal caso non hai bisogno di
scrivere NomeModulo.X ma puoi usare direttamente il nome della variabile
(cioe' X).
Happy Coding =)
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt

 (cioe' X).
tu dici?
secondo me le globali (che sono poi quelle pubbliche dichiarate nei moduli)
fanno solo confusione, magari non quando ce n'e' una, ma quando iniziano a
diventare un po'...
se vuoi davvero fare una cosa 'pulita' usa le property.
property let, property get. guardateli sulla guida.
bye, g.

 guardateli sulla guida.
Guardateli? Che sia guārdateli o guardāteli forse devi guardarli tu =)


 Guardateli? Che sia guārdateli o guardāteli forse devi guardarli tu =)
ho indicato due cose da guardare sulla guida... e' forse sbagliato dire
guardateli (guarda tu quei due cosi sulla guida)?
mah...
bye, g.

 mah...
Appunto, mah...


 Inoltre hai ignorato totalmente il resto del mio post.
ah, no, solo frainteso :)
ho ignorato il resto del tuo post perche' sono d'accordo e non ho nulla da
dire in merito, l'accenno alla guida non era per te :), ma per
SuperMarcoski, che aveva chiesto aiuto in merito.
sono sicuro che tu sappia di cosa stai parlando, non lo metto certo in
dubbio.
bye, g.

 ha scritto

uso vb dal gennaio 97. per le semplici app di database non ho mai sentito il
bisogno di un modulo di classe o di un property let/get. uno dei mie bas
tende sempre a chiamarsi basDeclare, e a essere pienotto di pubbliche, altre
ai declare dell'api. e i programmi che mi sono scritto, quando non li scrivo
in dormiveglia o sul piede sinistro, reggono da anni. se ci sono problemi,
derivano da un'analisi approssimativa, o da troppa frettta nel compilare,
non certo da un'implementazione o dall'altra.
forse paghero' -- ipotesi di h.p.l. a lupo -- il mio old style coding
passando ad ado, o forse passando a net, o forse posso continuare
beatamente. data la sostanziale immutabilita' del mio codice in cobol,
clipper e vb, propendo per l'ultima. anche perche' nella mia esperienza
quando si riprende in mano un programma, anche proprio, lo si riscrive da
capo. non ci si bagna due volte nello stesso fiume, gia' solo perche' e'
cambiato il bagnante.
qualcuno deve ancora spiegarmi in modo tale da convincermi per bene e
definitivamente a cosa serve creare un tipo "cliente" se la struttura del
tipo medesimo l'ho impostata bene nel db. personalmente dalla data division
in qua, a quella mi rifaccio.
che poi altri si trovino bene in altri modi, magnifico. ma se il programma
funziona correttamente, per favore smettiamola con il e' meglio questo e'
meglio quello. voi come dite forchetta ? io dico forchetta, ma preferisco un
programma arcaico che funziona a uno state of the art che non funziona. se
poi le due cose (modernita' e funzionamento, non le altre due :P) riescono
ad abbinarsi, tanto meglio.
tanto, quando uno scrive
    form2.show
sempre un goto sta scrivendo
solo che gli spaghetti li sta servendo en nouvelle cuisine.
per me conta che siano cotti giusti.
j.imho

 ad abbinarsi, tanto meglio.
Mi permetto (se posso) di sintetizzare/ribadire un concetto già ampiamente
altrove espresso:
Se ho un programma già fatto, funzionante, distribuito e utilizzato,
dovrò/potrò "solo" adeguarlo.
Se devo progettare/scrivere un programma (inteso come progetto) nuovo, sarei
un pazzo a non usare gli strumenti che, allora non c'erano. Ma, IMHO, solo e
quando sono necessari/utili/funzionali e, soprattutto, funzionanti, non
quando costituiscono soltanto "finezze stilistiche".

 ad abbinarsi, tanto meglio.
d'accordissimo... difatti sottolineo anche il secondo me del primo post.
io ho cominciato a programmare con qbasic, i miei """"""programmi""""""
erano zeppi di goto. poi ho scoperto vb, ma lo stile di programmazione non
e' cambiato, i goto erano sempre all'ordine del giorno (del resto, non
conoscevo altro modo di programmare). poi una persona mi ha illustrato a
grandi linee l'altro tipo di programmazione, quello piu' oop. da quel
momento ho cominciato ad usare le classi, ad implementare l'interfaccia di
ogni oggetto con le property ed a eliminare le variabili globali (se le uso
ne uso una, in genere anche quella una istanza di una classe, richiamata da
apposito connector). ora non riesco piu' a farne a meno, forse solo perche'
non sono mai stato capace di usare bene l'altro tipo di programmazione.
questo per dire, come avete gia' ribadito che alla fine e' solo una
questione di *gusti*. se un programma scritto nei due stili diversi funziona
correttamente e fa le stesse cose... buon per lui :)
bye, g.

 quando costituiscono soltanto "finezze stilistiche".
concordo abbastanza, anche se non in pieno. e' sul _funzionali_, prima
ancora che sul _funzionanti_, che ogni tanto nutro qualche dubbio.
e soprattutto lo nutro sull'assiomaticita' delle affermazioni. tu stai (e io
con te) smoccolando su ado, quando gia' qui e' stato ripetuto che 
ado.net
cambia abbastanza. non oso pensare ado.pallad, che probabilmente prima di
connettersi a un db chiedera' il permesso a bill. come dire, chi ha
riciclato codice suo personale di 10 anni prima cambiando solo una stringa
di connessione alzi la mano. ora o fra dieci anni, va bene lo stesso. e se
tanto devo riscriverlo, tendenzialmente lo riscrivo nel modo piu' veloce,
cioe' in quello che conosco meglio, se solo lo consente. se poi devo
prendere una tabella da oracle e una da mysql, ci penso: ma imho qualcuno
l'ha pensata male in partenza.
ciao, a.

 ha scritto nel messaggio
news:agh7ll$ltmar$1...@ID-51318.news.dfncis.de...


 programmatore che poi e' la stessa cosa) non dall'uso di globali.
mi permetto di dissentire perchè l'ingegneria del sw e i principi
dell'information hiding di Parnas impongono di evitare per quanto possibile
l'uso delle variabili globali in fase di progettazione.

Ah un altra domanda.
Il form da cui passo la variabile pubblica non è il form principale.
Cioè ho FORM1 (form principale), INSERT (form di inserimento dati)
AutoINSERT (form d'inserimento dati delle automobili).
Il form AutoINSERT viene richiamato da un bottone su INSERT e la variabile
globale da passare l'ho dichiarata du INSERT.
Il procedimento è lo stesso cioè NomeFORM.Variabile oppure
NomeFormPrincipale.FormSecondari.Variabile?
Ciao ciao Grazie

 ha scritto nel messaggio
news:KYVW8.51464$Jj7.1...@news1.tin.it...

sempre lo stesso. non c'e' distinzione ne' gerarchia tra quella che tu
chiami form principale e quelle secondarie.
bye, g.

 variabili pubbliche nei form ecc ecc
E' una cosa normale.
Ti consiglio spassionatamente (solo perche' non posso ordinartelo ;)) di
leggere il manifesto del newsgroup (in calce sotto la mia firma) prima
di continuare a postare.
In particolare occhio al quoting, ovvero citare il testo di un'altro
post e rispondere, che si fa *sotto* al testo riportato e non sopra,
curando di eliminare le parti non necessarie (quali saluti, firma,
ecc.).
Inoltre ti invito a leggere il messaggio [!]Un aiuto a tutti i newbie,
postato da me (Lokar) il 06/06/2002 alle ore 11.50. Se non lo trovi nel
tuo newsreader puoi cercarlo con googlegroups (
groups.google.it
) nel
newsgroup it.comp.lang.visual-basic, link diretto (da ricomporre su una
riga):
http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&group=it.comp.lang.vis
ual-basic
Happy Coding =)


 ma piu' le funzioni diventano delle matrioske. intanto, grazie della
dritta.
Hai ragione, ma permettimi un esempio reale:
Ho passato la giornata a rincorrere su un tot di progetti una singola
istruzione: .RecordCount
Siccome il RecordCount non l'ho in ADO+SQL Server (vecchio discorso) ho
dovuto sostituire tutte le chiamate a RecordCount con un
"t_rec=D_RICAVA_RECORDCOUNT(db, rs)"
Questa (nuova) Function "riconosce l'ambiente" e in caso di DAO farà un
rs.MoveLast e restituisce il valore di rs.RecordCount, in caso di ADO farà
tutto il suo bel casino.
Quale sarebbe stato il vantaggio se ci avessi pensato prima (ma prima non lo
sapevo!)?
Che oggi non avrei dovuto "ragionare" su ogni singola istruzione per sapere
qual è il db di appoggio (necessario solo ADO) del recordset aperto chissà
dove.
Beh, per onestà occorre aggiungere che non avrei mai pensato (a suo tempo)
di dover passare un db di appoggio per un semplice RecordCount e questo non
mi avrebbe risparmiato molto...

 "t_rec=D_RICAVA_RECORDCOUNT(db, rs)"
si', si'. su cp di questo o dello scorso mese c'erano due-tre paginette che
accennavano a come uniformarsi le chiamate ai vari dbms, mssql, oracle ecc.,
e l'idea era esattamente quella.
ciao, a.

 da capo.
Vedi quale è la diferenza... L'old style inevitabilmente
acquisito con l'utilizzo di un certo tipo di linguaggi, ti
porta a questo. Questa è una conseguenza del tuo stile, non
una causa...
Mi pare, con queste risposte, di rendermi estremamente
antipatico, ma non è mia intenzione (lo ripeto) criticare ciò
che fanno gli altri, ma cercare di aiutarli.
Io, che mi sono plasmato in C++, il che mi ha dato decisamente
un altro stile di programmazione, non ho mai dovuto riscrivere
(ed effettuare il debug di) più di un 5% del mio codice anche
in presenza di enormi cambiamenti, ben più grossi di un
passaggio DAO -> ADO o modifiche del genere.
Ma forse è solo una mia fissazione quasi paranoica...
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.