Newsgroup: it.comp.lang.visual-basic
Titolo: aggiungere un record ad una combo box

allora il mio problema è questo ho due form:
nel 1° una text box o anche una listbox
nel 2° una combo box
vorrei sapere come trasferire il testo della textbox o un record della
listbox e far si che diventi il primo record della combobox presente nel
secondo form.....
grazie a tutti in anticipo
--
JOSUKE HIGASHIKATA
------------------
Membro del JOJO FAN CLUB
Autore della HomePage italiana dedicata a
"Le bizzarre avventure di JOJO"
http://members.xoom.com/hirohikoa/index.html

...



Pessima soluzione, le variabili globali per fare queste cose sono da evitare
come la peste.
Basta fare, da Form1:
Form2.Combo1.AddItem Text1.Text
lo stesso dicasi per la listbox.
--
Roal Zanazzi
z...@iol.it

 Form2.Combo1.AddItem Text1.Text
ok, ma si può fare molto di meglio...
e se magari volessi validare (cioè controllare) il dato da inserire nella
combo?
e se un bel giorno cambiassi la Combo con un altro controllo?
e se....
sono reduce da una (pesante) opera di restyling di un programma
spaghetti scritto in VB5 ... e ne ho le [CENSURA] piene di programmi
che fanno acqua da tutte le parti (non me ne vogliate...)
per realizzare il tutto in maniera pulita e per evitare future brutte
sorprese
in questi casi consiglio a tutti di fare un largo uso di "properties" e
"methods";
il caso della Combo di cui sopra potrebbe essere realizzato come segue:
' Sub da inserire nel file Form2.frm
Public Sub AddNewItem(ByVal strItem As String)
    Combo2.AddItem strItem
End Sub
' esempio di utilizzo
...
Form2.AddNewItem "Prova"
a questo posso usare tranquillamente il nuovo metodo "AddNewItem"
e il giorno che, ad esempio, avrò la necessità di cambiare la Combo
con una ListBox dovrò solamente cambiare la Sub opportuna (evitando cioè
di correre dietro a tutte le possibili chiamate a "Form2.Combo1.AddItem")
per passare poi dati tra form consiglio caldamente a tutti di utilizzare
il meccanismo delle "properties" o di variabili membro"Public"
ciao.

come la peste.
grazie per la "pessima soluzione"  :-))
tuttavia non ho mai avuto problemi di peste utilizzando anche 100 global.
Piuttosto mi sembra un problema di interpretazione nel senso che ognuno
adotta un determinato criterio in base alle proprie esigenze. Per quel che
mi riguarda spesso e volentieri sono costretto a condividere più dati con
parecchie form e la soluzione "global" mi è sempre sembrata la più idonea..
probabilmente hai ragione tu quando dici che con una semplice riga (vedi
esempio "form2.combo.additem text1.text" ) eviti la global, ma se l'amico
avesse bisogno di controllare una serie di input da gestire su più form e
quindi di di condizionare l'inserimento nella combo ? beh probabilmente in
tal caso ti vedio necessitato a memorizzare il tutto in modo da renderlo
disponibile in ogni form del progetto o al più salvi sistematicamente su
file temporanei per non sovraccaricare la memoria...  resto dell'idea che si
tratta di diverse interpretazioni
ciao
Davide

 wrote in message 7r6q8e$hdi$1...@nslave1.tin.it...



è quello che ho fatto ioooooooo eh eh
non mi è stato d'aiuto usare le variabili globali che tra l'altro non so
come si impostano
ma cmq alla fine ci sono riustoooo

 resto dell'idea che si tratta di diverse interpretazioni
Ok, capisco le tue motivazioni.
Mi sono fatto una cultura (anche se nemmeno sufficiente, a mio parere) sulla
programmazione ad oggetti (non nel senso di usare un linguaggio ad oggetti,
ma nel senso di "pensare ad oggetti", che non sono necessariamente la stessa
cosa). Quindi tendo ad affrontare i problemi con _quel_ punto di vista.
Nella filosofia OOP (che, bada bene, si puo' adottare anche in linguaggi non
OOP, come il C o VB), un criterio molto importante e' l'INFORMATION HIDING
(o incapsulamento), ossia quel criterio per cui un oggetto (nel nostro caso
una form) rende pubblico agli altri oggetti _solo_ il minimo indispensabile
(detto interfaccia) e null'altro.
Capirai bene che, in uno scenario come quello "ideale" dell'OOP,
oggetti/variabili globali sono quanto di peggio si possa pensare.
Facciamo un esempio pratico: un uomo deve suonare un campanello.
Non ti sembra piu' logico che:
UOMO  ->  CAMPANELLO.SUONA
piuttosto che:
UOMO -> GLOBALSUONA = True
CAMPANELLO.SUONA = GLOBALSUONA
? (forse l'esempio non e' venuto bene, ma spero si capisca lo stesso).
Inoltre (e questa e' esperienza maturata da qualche decennio e qualche
centinaio di migliaia di programmatori) un programma costellato da variabili
globali e' molto piu' difficile da manutenere, piuttosto che uno ben
strutturao (secondo, appunto, i dettami "filosofici" della OOP).
So benissimo che il programma funziona ugualmente, ma prova a doverlo
modificare tra uno o due anni (o piu'), poi quando bestemmierai perche' non
ricordi in quali particolari circostanze veniva usata quella particolare
variabile globale, allora, forse, avrai capito...
Perennemente OO,
--
Roal Zanazzi
z...@iol.it


penso che per ogni problema è possibile valutare una serie di soluzioni;
ciascuna soluzione vale caso per caso.
ciao
Davide


ti do pienamente ragione a proposito della manutenzione delle Global. Se
abbandono un progetto per un paio di settimane dimentico quasi il 50% delle
global per ciascuna form. Però ho scoperto che con un pò d'ordine e qualche
riga di commento è facile riorganizzare il lavoro :-))
ciao Davide


Ma i commenti e l'organizzazione del codice non sostituiranno MAI un buon
design ;-)
--
Roal Zanazzi
z...@iol.it

 wrote in message 7ra5cd$2g9$1...@nslave1.tin.it...





 >



Diciamo che mi sono messo a leggere la documentazione "UML Semantics" (ho
iniziato dalla piu' semplice, eh? 8-), ma per mancanza di tempo, ho
temporaneamente sospeso.
Comunque se vuoi parlare di UML:
1) questo thread non e' adatto
2) al limite puoi fare un thread nuovo (anche se leggermente OT)
3) se nessun'altro e' interessato, puoi contattarmi via e-mail, l'argomento
mi interessa, anche se mi manca il tempo per approfondirlo.
--
Roal Zanazzi
z...@iol.it

il tema e' diventato davvero interessante, ma cambiate il soggetto!
grazie, pal