List-Control à la Firefox' Download-Manager

Ich kompiliere meine Projekte stets mit dem neuesten Framework und somit auf dem neuesten Stand der Technik.

Ich muss mich mir leider nocheinmal melden, da ich nicht ganz damit klarkomme. Das Zeichnen eines Items läuft völlig problemlos ab. Aber da ich mit dem Control ja einen Download-Manager machen möchte, muss ich immer wieder die Daten, welche vom jeweiligen Download kommen, erneuern und dann auch in der DownloadList erneuern. Und genau das bekomme ich nicht richtig hin. Ich habe da jetzt schon lange drangesessen aber es noch nicht hinbekommen. Ich hoffe ihr könnte mir da helfen.

Die Datenübergabe beim Hinzufügen eines Downloads erfolgt über eine Struktur. Das klappt auch problemlos. Dann ist aber die Sache, wie ich die Downloads einzeln refreshen kann, damit meine ich, wie ich die Daten in der DownloadList erneuern kann.

Nimm keine Structure sondern eine Klasse. Das erspart im Zweifelsfall Ärger. Nachdem du die Daten des Objektes der Klasse, das das Item repräsentiert, geändert hast, rufst du die Refreshitem()-Methode der Listbox auf, damit das Item auch aktualisiert wird.

edit: Oder du bindest die Liste der Objekte per Datasourcean die Listbox.

Könntest du mir das mit der Klasse genauer erklären? Meinst du das so wie bei der ListView ein ListViewItem?

Ja, ich habs beim Testen so gemacht, dass ich eine Klasse namens Item erstellt habe, die halt einen Titel, eine Beschreibung, ein Icon und einen Tag hat. Es kann sich auch selbst zeichnen. Im DrawItem übergebe ich nur das Graphics-Objekt, die Bounds, und ob es selektiert ist oder die Maus sich darüber befindet. Neue Einträge fügt man dann so hinzu:
Das war nur zum Testen gedacht. Evtl ist es sinnvoller, eine List(Of Item) zu erstellen und diese dann per DataSource an die Listbox zu binden.
Ohne die Liste könnte man Werte so ändern:

RefreshItem() ist nur innerhalb der Listbox selbst aufrufbar,s ehe ich gerade. Da könnte man sich aber ja noch etwas basteln, um nur das eine Item neu zu zeichnen.

1. Und wie kann ich dann mit dem DataSource im DrawItem arbeiten?
2. Ist es besser wenn das List-Control die Elemente zeichnet oder wenn sich die Elemente selber zeichnen?

Jonas Jelonek schrieb:

1. Und wie kann ich dann mit dem DataSource im DrawItem arbeiten?

Habe ich noch nie gemacht. Ändert das überhaupt was?

Jonas Jelonek schrieb:

2. Ist es besser wenn das List-Control die Elemente zeichnet oder wenn sich die Elemente selber zeichnen?

Ich finde es schöner, wenn die sich selber zeichnen. Aber du musst halt aufpassen, da die Items eine ObjectCollection sind. Da können auch andere Dinge drin sein, die du nicht einfach casten kannst, wenn zum beispiel jemand einfach nur einen String hinzufügt (geht im Designer).

Wie übergibst du dem Item das Graphics-Objekt?

ich bin übrigens annerer Ansicht als vb-checker.

ich würde die Daten nicht zu selbst-zeichnenden Daten erweitern, sondern das würde ich inne Zuständigkeit der Listbox belassen, bzw. des ItemDraw-Events.
Innerhalb der Daten ist nix für das Zeichnen wesentliches, also man müsste alles von aussen hineingeben: Graphics, Position, Abmaße.
Jo, und wo man alles von aussen hineingeben muß, kann man ebensogut gleich von aussen malen.

Jonas Jelonek schrieb:

Wie übergibst du dem Item das Graphics-Objekt?

ganz einfach mit Draw(e.Graphics, ...). Der Paramter muss dabei nicht mal ByRef sein, einfach ByVal gr as Graphics.

ErfinderDesRades schrieb:

Innerhalb der Daten ist nix für das Zeichnen wesentliches, also man müsste alles von aussen hineingeben

Titel, Beschreibung und Icon. Aber das bleibt natürlich "Geschmackssache". Zumindest fallen mir keine offensichtlichen Nachteile auf.

ByRef hätte da keinen Sinn.

Ich werde dem Item jetz auch einfach das Graphics-Objekt übergeben und es zeichnet sich selbst, damit ist der Aufwand m.M.n. nicht so groß.

jetzt sind mir doch noch paar argumente eingefallen:

Also erstmal, das DrawItem-Event fordert den ZeichenVorgang vonne Listbox, nicht vom Daten-Item. Wieso muß man das jetzt ins Item umdirigieren? Also auch wenns keinen Nachteil hat, hats denn einen Vorteil?

Bei Spielfiguren ist das was anneres, die müssen ja selbst wissen, wie sie aussehen, und wo sie positioniert und wie ausgerichtet sind.

Aber genau diese Dinge weiß beim Ownerdrawing Listbox doch die Listbox, nicht das Item.
Und nochmal bisserl umständlicher wirds, weil ja nicht nur Position und Abmaße von der Listbox vorgegeben sind, sondern auch, ob das Item selectiert ist.

Eigentlich hatte ich einen Plan wie ich das mache, wenn die Items sich selbst zeichnen. Wenn ich jedoch das Control die Items zeichnen lasse, weiß ich nicht so recht, wie ich das machen soll. Denn die Argumente von ErfinderDesRades überzeugen mich so langsam, dass es besser ist, wenn das Control die Items zeichnet, nur weiß ich nicht so recht wie ich das machen soll.

ich hatte doch auf ein Beispiel verlinkt.

Stimmt, hatte ich ganz vergessen. Werde ich mir jetzt mal richtig ansehen und versuchen, ob ich es hinbekomme.

Jonas Jelonek schrieb:

nur weiß ich nicht so recht wie ich das machen soll.

Da ist doch gar nichts anders? Gibt es konkrete Fragen?

Ich wüsste nicht, wie ich das mit der Datenübergabe machen sollte, da das DrawItem-Event nichts zum Item liefert.

Ich werde mir jetzt aber das Beispiel von ErfinderDesRades genauer angucken und sehen was ich daraus machen kann.

Jonas Jelonek schrieb:

da das DrawItem-Event nichts zum Item liefert.

e.Index. Das ist in Verbindung mit Me.Items() relativ vielsagend.

Stimmt. Ist mir noch garnicht in den Sinn gekommen. Ich werde das wahrscheinlich damit machen, da mir das mit DataSet und BindungSource etwas kompliziert ist, denn wenn ich das richtig verstanden habe nach dem Tutorial von ErfinderDesRades muss ich für jede Information, die gezeichnet werden soll, ein eigenes BindungSource erstellen.

Ich werde jetzt mal versuchen mir eine eigene Collection für meine Items zu machen, dann die Items-Property zu überschreiben und dann kann ich damit arbeiten.

Jonas Jelonek schrieb:

Ich werde jetzt mal versuchen mir eine eigene Collection für meine Items zu machen, dann die Items-Property zu überschreiben und dann kann ich damit arbeiten.

So hatte ich das am Anfang auch versucht. Aber da hatte ich nur Probleme mit, zum Beispiel habe ich das Editieren der Liste im Designer nicht hinbekommen, da gibt es immer wenig sagende Fehlermeldungen. Und falls du mitbekommen willst, dass sich was verändert hat, muss man wohl ObservableCollections nehmen oder so.
Kurz: Ich habe an der Items-Auflistung überhaupt nichts geändert und einfach meine Items dort reingeworfen. Jetzt prüfe ich halt vor dem zeichnen, ob die den richtigen Typ haben, ansonsten rufe ich toString() auf.