Newsgroup: it.comp.lang.visual-basic
Titolo: aiutino su textbox

se voglio visualizzare il contenuto di una textbox (es. pippo) in un altra
textbox dello stesso form uso questa sintassi :
Text1.Text = "pippo"
Text2.Text = (Text1.Text)
Ma se la textbox 2 si trova in un altro form come devo scrivere il codice?
Grazie 1000.

 ha scritto nel messaggio
news:ApUKa.124633$Ny5.3...@twister2.libero.it...

nomeform.text2.text = text1.text

 nomeform.text2.text = text1.text
Che, imho, è concettualmente sbagliato.
Ciao

 Che, imho, č concettualmente sbagliato.
Perchč?

 > nomeform.text2.text = text1.text

 Perchč?
Perchč gli oggetti dovrebbero essere invisibili all'esterno del form.
Un form dovrebbe essere inteso come un oggetto a se stante, e tu 
dovresti interagire con esso senza doverti preoccupare di come si 
chiamano gli oggetti in esso contenuto.
E' un po' come dire che quando chiami una funzione tu ti devi 
preoccupare di inizializzare dall'esterno la variabile che la funzione 
usa nei loop, conoscendone quindi il nome.
Non so se mi sono spiegato.
Ciao

 dov'é lo sbaglio scusami?
Lo sbaglio è concettuale.
Perché così trasformi una "scatola nera" (il form)
in una "scatola grigia" (un qualcosa che "devi sapere"
come funziona per interagire con esso), mentre la
progettazione strutturata suggerisce di usare solo
parametri esterni (e il meno possibile) per comunicare
tra moduli.
--
Er Roscio.

[*Zanna* : 
znt....@virgilio.it
] ha scritto:

Sě, ti sei spiegato, ma chi non lavora per classi (ovvero non ha voglia di
crearsi strutture di interfaccia fra uno o piů form quando immediatamente
disponibili dai form stessi) trova piů semplice e immediato interfacciarsi,
appunto, fra piů form usando i loro oggetti, come se (e di fatto cosě č)
facessero parte della stessa "logica". Un esempio č una serie di
informazioni (per esempio relative a un articolo di magazzino) che, per
questioni di spazio fisico/grafico e/o di organizzazione, vengono separate
su piů form.

 tra moduli.
Vedi anche la mia risposta a Zanna. Considero un form, quando
concettualmente legato a un altro (o piů), una scatola assolutamente bianca,
usato esclusivamente per questioni estetiche o di spazio. Non č quindi una
funzione generica che, giustamente, deve restare tale.

 funzione generica che, giustamente, deve restare tale.
Beh, lo facciamo un po' tutti nella pratica,
ma in teoria, ciascun modulo, perfino ciascun
blocco "do" o "if" dovrebbe essere una scatola nera.
Del resto, VB ci mette a disposizione la tecnologia
per rendere un form completamente "isolato".
Siamo noi che dovremmo sforzarci di renderlo
tale, sempre che lo sforzo ne valga la pena.
--
Er Roscio.

non sono mica tanto d'accordo sulla questione Zanna-Lupo. Magari č anche
giusto dire che un form dovrebbe essere una scatola chiusa, ma dirlo cosě a
priori č scorretto.
Ci sono molti form che "collaborano" tra di loro (immaginiamo per esempio
Winamp: c'č la finestra principale e la finestra della playlist), cioč
finestre a pari livello che possono/devono poter compilare i controlli l'una
con l'altra, per cui č necessario che ciascuno conosca la struttura
dell'altro.
altri esempi: quando si disegna un report di access, cioč la finestra di
design del report stesso, piů la finestra con l'elenco dei campi. io posso
col drag'n'drop trascinare un campo da quest'ultima finestra su quella del
design.
non so, ripeto. Va bene il discorso teoricamente, ma non sappiamo cosa deve
fare Sara, per cui obiettare fin da principio sul metodo non mi sembra
salutare.
good coding!!!
-- 
Damiani Liborio Igor
ig...@igordamiani.it
 - 
soft...@igordamiani.it
 - 
idam...@hotmail.com
http://www.igordamiani.it
ICQ : 11847262

 tale, sempre che lo sforzo ne valga la pena.
... e che se ne abbia il tempo...

Posso rispondere nel mezzo ?
Secondo me nella realta' la formgestione e' una scatola nera verso la form
magazzino e parlano tra loro tramite terze strutture, pero' e' anche vero
che la form magazzino e' completamente bianca col la form dettagli che viene
caricata con text1.text = formchiamante.text1.text !
Ecco, l'unico appunto che al posto di fare dalla form chiamante
nomeform.oggetto.proprieta = oggetto.proprieta
faccio
oggetto.proprieta = nomeform.oggetto.proprieta
al load della form chiamata
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

 al load della form chiamata
Non ho capito. Cosa sarebbe oggetto.proprieta, per esempio?
Inoltre, se escludiamo preparazioni delle proprietà (per esempio di vari
textbox), perchè assegnare a un (mi par di dedurre) nuovo oggetto qualcosa
che è comunque disponibile? Perchè, cioè, creare un'altro oggetto o
variabile? Leggibilità? Beh, io non chiamerò mai un textbox Text1, ma,
semmai, codice_articolo, oppure descrizione_articolo. Tale nome è
chiaramente univoco nel form di appartenenza sin da progetto e lo diventa
per tutto il progetto anteponendo il nome del form (che non sarà un muto
Form1). Il problema vero, secondo me, nasce solo per form modali che
all'unload (necessario per tornare al chiamante) perdono tutto, allora
occorre salvare quel che serve in variabili comuni al form stesso (che sta
morendo) e al form chiamante (che ne ha bisogno per rilevare, per esempio,
le scelte fatte dall'operatore). Variabili globali? Scrittura su file?
Registro? Io vado tranquillo con la prima. Quante? Una sola in tutto il
progetto. Un'unica stringa nella quale metto tutto ciò che al chiamante
serve, separando le varie informazioni con mie "Tags" univoche.

 ... e che se ne abbia il tempo...
Anche !... :-)))
--
Er Roscio.