Silverlight ListBoxItem.Tag

[Günther Weber]

Ein ListBoxItem ist das Element in einer ListBox.

Ein ListBoxItem hat die Eigenschaft Tag, der ich gern Daten zuordnen würde.

Jetzt könnte ich erst ein ListBoxItem definieren, Tag zuweisen, aber wo trage ich den Text ein, und wie kriege ich das Item in die ListBox?

Oder ich füge erst mit Add oder Insert den Text in die ListBox ein, aber wie komme ich dann an das ListBoxItem um nachträglich die Daten zuzuweisen?


In meiner Anwendung habe ich eine Liste, die in jedem Datensatz einen Hersteller, eine Typenbezeichnung und weitere Daten enthält. In einer ListBox sollen alle Hersteller, in einer weiteren alle Typen des in der ersten ListBox selektierten Herstellers aufgelistet sein. Um anschließend direkt auf den richtigen Datensatz zuzugreifen, möchte ich die Daten aus Tag auswerten. Nach einer Herstellerauswahl hätte ich einen Bereich (von - bis) aus dem ich alle Typen in die zweite Liste schreiben kann, bei einer Typenauswahl den genauen Index des gesuchten Datensatzes. Ansonsten müßte ich die gesamte Liste durchsuchen um den gewünschten Datensatz via Stringvergleich zu finden. Bei über 2800 Datensätzen dauert das etwas.

Danke
Günther

[fanderlf]

Warum baust Du Dir denn nicht eine entsprechende Datenstruktur auf und machst das ganze über DataBinding:

public class Customer
{
  public String Name { get; set; }
  public IEnumerable<CustomerType> Types { get; set; }
}
 
public class CustomerType
{
  public String Name { get; set; }
  public String Customer { get; set; } //optional - nur wenn du es bidirektional brauchst
}

Wählt jemand einen Eintrag in der Liste aus hast Du auch direkt die passenden Typen und kannst die 2. ListBox füllen. Wenn Du eine Lazy Variante brauchst (also die Daten werden erst geladen, wenn jemand in ListBox Customer etwas auswählt), dann verwendest Du statt der CustomerType Objekte einfach nur die CustomerTypIds. So hast Du schnell alle Information zur Hand und musst nichts in ominösen Tag Properties speichern

[Günther Weber]

Zitat von fanderlf

Warum baust Du Dir denn nicht eine entsprechende Datenstruktur auf und machst das ganze über DataBinding:

weil so etwas noch zu neu für mich ist

Danke, ich werds auch bald können...
Günther

[Günther Weber]

Es handelt sich um Daten, die entsprechend dem Vorschlag von gfoidl aus diesem Thread http://entwickler-forum.de/showthread.php?t=63020 eingebunden sind. Allerdings eine andere Datei und ohne Datagrid. Wenn ich es richtig verstanden habe, müßte ich bereits diese Daten Deinem Vorschlag entsprechend speichern, da ich sonst unnötig Speicherplatz verschwenden würde. Das werde ich mit Sicherheit später noch tun.

Meine "langsame" Routine hab ich noch etwas beschleunigen können und spüre keinen Zeitunterschied mehr zwischen Klick und Rückmeldung, dass er richtig aussgewählt hat. Gestern war es so eine halbe Sekunde.

LG, Günther

[gfoidl]

Hallo,

ich will das von Florian nochmal unterstreichen:

So hast Du schnell alle Information zur Hand und musst nichts in ominösen Tag Properties speichern

Wichtig ist die Trennung von UI und Logik. D.h. auch dass in der UI keine Daten gespeichert werden sollen und somit ist die Tag-Eigenschaft auch nicht zu verwenden.

Mit irgendeinem Muster wie MVC, MVP, MVVM (sind alle irgendwie ähnlich) lässt sich das mit Datenbindung wunderbar umsetzen. In der UI muss und soll nichts durch irgendwelche Klimmzüge gespeichert werden. Siehe dazu auch das Beispiel im obigen Link. Da wird alles per Bindung bewerkstelligt.

Warum ist Trennung von UI und Logik überhaupt sinnvoll?
Um keine ausufernde Antwort zu geben sollte der Hinweise auf "Trennung der Anliegen" reichen Ich könnte auch schreiben da es sonst keine sauberer Entwurf ist.


mfG Gü

[Günther Weber]

Zitat von gfoidl

Warum ist Trennung von UI und Logik überhaupt sinnvoll?

Das sehe ich ja schon selbst, wenn ich mir meinen Windows-Form Quelltext anschaue und nachdenke, welche Teile man wohl relativ einfach direkt in die Silverlight Anwendung übernehmen könnte.

[fanderlf]

Das blöde an der ganzen Geschichte ist, dass mans leider meistens erst viel zu spät merkt, wenn nicht jemand da ist der einen zwingt es so zu machen. Glaub auch bloß nicht, dass es super einfach wäre so eine Architektur aufzuziehen. Das Problem an der Sache ist nämlich, dass man eher in Objekten denken muss. Nicht mehr so nach dem alten Schema: "Zuerst mach ich das, dann mach ich das und dann mach ich das..."

Anfangs ist das ganze wirklich schwierig, weil man sich mit einer ganzen Flut an Themen auseinandersetzen muss. Aber je weiter man durchsteigt, desto mehr Spaß macht es so zu programmieren, weil man unglaublich flexibel wird.

Durchhalten ist die Devise!!!!

[Günther Weber]

So ein Programm hatte ich zuvor in C, ganz ohne Objektorientierung. Als ich es dann 2006 mit C# neu aufgebaut hatte, habe ich mich schon wahnsinnig gefreut, um wieviel übersichtlicher der Code geworden ist. Aber jetzt will ich es perfekt machen...

[fanderlf]

Perfekt geht eigentlich fast nicht das lerne ich auch bei jedem Projekt wieder. Ich denke mir auch bei jedem Projekt:
Oh das haste aber dieses mal schick gemacht. Und alles ist so toll und so elegant. Und ein halbes Jahr später wenn ich drüber schau fallen mir schon wieder 30 Sachen ein die man hätte besser machen können. Aber das geht wohl jedem so.
Wenn Dich das Thema wirklich interessiert möchte ich Dir mal folgende zwei Bücher ans Herz legen:

http://www.amazon.de/Domain-Driven-D...0736106&sr=8-1

http://www.amazon.de/Applying-Domain...0736106&sr=8-3

Diese Bücher beschreiben die Basisprinzipien gut organisiert Software. Diese Bücher sind interessant egal welche Software man schreibt.

[Günther Weber]

Zitat von fanderlf

public class Customer
{
  public String Name { get; set; }
  public IEnumerable<CustomerType> Types { get; set; }
}
 
public class CustomerType
{
  public String Name { get; set; }
  public String Customer { get; set; } //optional - nur wenn du es bidirektional brauchst
}

Name in Customer wäre der Herstellername, das ist die erste Spalte meiner CSV Datei.

Name in CustomerType wäre die Typenbezeichnung, das ist die zweite Spalte in meiner CSV Datei. Die Datenbindung sieht dann vermutlich so aus: (werde ich heute Nachmittag so ausprobieren)

private void BindListBox()
{
  listBox1.DataSource = NameDerCustomerListe;
  listBox1.DisplayMember = "Name";
}

Die zusätzlichen Daten, also die restlichen Spalten der CSV Datei könnten direkt in CustomerType gespeichert werden. Das wäre die Speicherplatz sparende Variante.

Dann soll aber später noch ein Filter dazukommen, damit der Anwender nur bestimmte Typen angezeigt bekommt. Würde doch bedeuten, daß ich in dem Moment diese Listen neu aufbauen muß. Dann habe ich also die CSV Datei im Arbeitsspeicher und zusätzlich diese Listen, die dann allerdings ohne die zusätzlichen Daten. Oder kann man in beiden Klassen ein bool Feld hinzufügen, und "Name" nur dann in der ListBox zulassen, wenn dieses Feld true ist?

Danke - Günther