Combobox con corrispondenza testo-valore

mercoledì 02 luglio 2008 - 17.09

Luka90 Profilo | Junior Member

Ho un grosso problema.

Un amico mi ha parlato della potenzialità in altri linguaggi di inserire in una Combo un valore e un testo, cosìcchè nell'eventualità di caricare i suoi items con il risultato di una query, ad ogni testo sia assegnato anche un numero che nel caso potrebbe essere l'ID che desidero.

Dato che ITEMS richiede un Object, ho provato a creare una nuova classe che faceva al caso mio (trovata su un sito).

class ComboBoxItem
{
public string Name;
public int Value;
public ComboBoxItem(string Name, int Value)
{
this.Name = Name;
this.Value = Value;
}

public override string ToString()
{
return this.Name;
}
}

Ci sono altri modi?

Grazie dell'aiuto


Luca

freeteo Profilo | Guru

ciao,
si, il motivo di avere un object come item sta nel fatto che la combo rappresenta una lista selezionabile di oggetti, tipicamente di classi tue che rappresentano qualcosa.

Tipicamente sarebbe da usare in combinata con "DisplayMember" e "ValueMember" che sono le proprietà della collezione sottostante impostata nella proprietà "DataSource".
Ti faccio un esempio classico:

List<Articolo> lista = ArticoloManager.GetAll(); comboBox1.DataSource = lista; comboBox1.DisplayMember = "Descrizione"; comboBox1.ValueMember = "Codice";
dove Articolo è appunto una classe:
public class Articolo { public int ID { get; set; } public string Codice { get; set; } public string Descrizione { get; set; } public DateTime Data { get; set; } }

che viene riempita leggendo dal database, e viene scritta sul db quando è il momento di salvare, mappando i campi (sia lodato Linq )
Quando devi prederti i dati scelti dalla combo, ti basta un codice di questo tipo:
Articolo articolo = comboBox1.SelectedItem as Articolo; if (articolo != null) //--- se ha scelto qualcosa { ... }

Questo approccio, ti aiuta moltissimo, perchè spesso hai bisogno di avere altre proprietà dell'elemento selezionato, non ti basta l'id, perchè magari ti tocca rifare la query per leggerle etc...se invece lavori ad oggetti, vai via tranquillo perchè quello che ti serve lo puoi agganciare alla combo e poi recuperarlo.
Quindi ti consiglio vivamente questo approccio, anche se più laborioso all'inizio (farti le classi etc...) ti porta assoluti benefici in futuro nella manutentezione, implementazione, design dell'applicazione..assolutamente da farlo diventare "il modo" di programmare.
La cosa vale anche se hai DataTable al posto della tua List<T>, puoi passarla come datasource alla combo, e scegliere le 2 colonne che ti interessa visualizzare/utlizzare.

Ovvio che si può usare anche qualcosa di semplice come la sola stringa, ma diciamo che per "coprire" un'ampia gamma di casistiche, l'item della griglia è obbligatoriamente object.

ps: ho fatto un "volo pindarico" ma ci vorrebbero delle applicazioni reali per capirne il beneficio, cmq spero di averti almeno dato un possibile intuizione per progettare la tua applicazione, anche perchè la stessa cosa vale per la listbox etc...

ciao.

Matteo Raumer
[MCAD .net]
http://blogs.dotnethell.it/freeteo

Luka90 Profilo | Junior Member

Magnifico!

Bhe non c'è che dire, è una macchina potente questa combinazione! Sicuramente meglio di quanto stavo facendo con quella classe sopracitata.

Grazie mille della dritta!!!

Ora l'unica scocciatura è rimodificare tutte le funzioncine che mi riempivano le combo con una query e predisporre nelle set dele classi che vado a farmi (se ho capito bene una per ogni tabella che uso) anche le query di inserimento al DB.

Quindi od ogniuna di queste classi dovrò passare l'oggetto OdbcConnection oppure connettermi all'interno (quindi passare la stringa di connessione), corretto?
Nell'esempio citi la classe ArticoliManager. nel mio caso ne avevo creata una sola per interagire con tutte le tabelle. Forse ora è il caso che la dividi in tante "manager" così ogni tabella ha la sua


Luca

freeteo Profilo | Guru

>Bhe non c'è che dire, è una macchina potente questa combinazione!
>Sicuramente meglio di quanto stavo facendo con quella classe
>sopracitata.
eh si, è la struttura O-O layered, un classico della programmazione, che nel piccolo può essere trascurata, ma che io consiglio "sempre" visto i benefici di solidità e struttura che porta


>Grazie mille della dritta!!!
di nulla,ho fatto molto "veloce" ma penso che tu abbia capito l'approccio


>Ora l'unica scocciatura è rimodificare tutte le funzioncine che
>mi riempivano le combo con una query e predisporre nelle set
>dele classi che vado a farmi (se ho capito bene una per ogni
>tabella che uso) anche le query di inserimento al DB.
chiaro, devi fare 1po di codice in più all'inizio come ti dicevo, ma se fortunatamente hai tool come Linq puoi far fare questa scocciatura tutto a lui con mooooolto meno sforzo.


>Quindi od ogniuna di queste classi dovrò passare l'oggetto OdbcConnection
>oppure connettermi all'interno (quindi passare la stringa di
>connessione), corretto?
>Nell'esempio citi la classe ArticoliManager. nel mio caso ne
>avevo creata una sola per interagire con tutte le tabelle. Forse
>ora è il caso che la dividi in tante "manager" così ogni tabella
>ha la sua
si certo, il manager applica la "logica" poi dietro di lui dovrebbe starci il "dataprovider" che è quello che gestisce la CRUD (create, read,update,delete) con il db vero e proprio, se domani cambi il db, cambi solo questa dll.

Vedi tu che profondità vuoi dare, dipende anche da quanto grossa è l'applicazione, ma cmq gli strati vanno sempre rispettati il più possibile, perchè ti aiutano in futuro, dato che nel nostro lavoro, "l'unica costante è il cambiamento"

ciao.

Matteo Raumer
[MCAD .net]
http://blogs.dotnethell.it/freeteo

Luka90 Profilo | Junior Member

>eh si, è la struttura O-O layered, un classico della programmazione,
>che nel piccolo può essere trascurata, ma che io consiglio "sempre"
>visto i benefici di solidità e struttura che porta.

Chiaro, e ti ringrazio anche per la denominazione, così ora ci faccio un figurone

>chiaro, devi fare 1po di codice in più all'inizio come ti dicevo,
>ma se fortunatamente hai tool come Linq puoi far fare questa
>scocciatura tutto a lui con mooooolto meno sforzo.

Linq... So che è una libreria, ma non credo di averla mai sfruttata

>si certo, il manager applica la "logica" poi dietro di lui dovrebbe
>starci il "dataprovider" che è quello che gestisce la CRUD (create,
>read,update,delete) con il db vero e proprio, se domani cambi
>il db, cambi solo questa dll.

Certo! Avendo 5 tabelle differenti dovrò fare 5 Manager che si appoggiano ad un altra classe che contiene la serie di proprietà che mi vanno ad operare su quella tabella (nel tuo esempio, ManagerArticoli e Articoli).
Unica cosa che mi sfugge è il costruttore di quelel classi. Ogni oggetto dovrà avere nello stato l'ID no?
Usando un ODBC teoricamente dovrebbe avere la compatibilità con tutti i tipi di DB!

>Vedi tu che profondità vuoi dare, dipende anche da quanto grossa
>è l'applicazione, ma cmq gli strati vanno sempre rispettati il
>più possibile, perchè ti aiutano in futuro, dato che nel nostro
>lavoro, "l'unica costante è il cambiamento"

Questa me la devo segnare

Grazie mille (di nuovo)!!!
Luca
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5