[.NEt 2.0] ListBox zeigt keine gebundenen Daten an?

[Phoenix]

In diesem Beitrag hier hab ich versucht eine Enum in eine Grid zu bekommen. Das hat dann auch wunderprächtig funktioniert.

Mit einem extrem ähnlichen Code versuche ich nun, eine Liste in eine ListBox zu bekommen, aber die Listbox zeigt nix an:

Code:

// Get available roles for Selection list:
_rightsRoleList = new RoleList();
_rightsRoleList.Init();

// put roles to source
_srcRightsRoleList = new DataBindingSource();
_srcRightsRoleList.DataSource = _rightsRoleList;

// put source to ListBox
lstBoxRightsRoles.DisplayMember = "Name";
lstBoxRightsRoles.DataMember = "Name";
lstBoxRightsRoles.DataSource = _rightsRoleList;

Nun ist die ListBox aber weiterhin leer :-(

Die Liste hat Items, beim Debuggen werden auch beide Einträge angezeigt, aber auf dem UI ist nix zu sehen. Anscheinend sind die WinForms Controls nicht so ganz trivial, im Web-Bereich hab ich da nie wirklich Probleme mit gehabt... Was hab ich denn hier vergessen? Bei der Grid reicht das hier vollkommen aus. :gruebel:

[Elvis]

Zitat:

Zitat von Phoenix

Die Liste hat Items, beim Debuggen werden auch beide Einträge angezeigt, aber auf dem UI ist nix zu sehen.

Jetzt wäre natürlich noch schön zu wissen was da drin steht.
Ist RoleList auch wirklich von List<T> oder BindingList<T> abgeleitet, bzw implementiert es generische Interfaces? Wenn nicht würde ich sofort dort ansetzen, weil sie einfach zu furchtbarem (1.1-like) IL-Code führen was Iterationen angeht und man kann sowas mit keinen generischen Methoden benutzen.
Ich glaub(t)e dass hier dein Problem liegen könnte, da dein "strongly" typed container nicht die PropertyListe seiner Items an den BindingContext liefern könnte.
Das Erben von einer generischen Liste (welche BCL-Liste auch immer) sollte das Problem beseitigen.

Nachtrag1: Lol! jetzt sehe ich erst, dass du den DataMember besetzt, obwohl "Name" ganz sicher kein Container ist, right? Ich habe wie oben zu lesen ist schon nach esotherischen Problemen gesucht.
Einfach DataSource besetzen und DisplayMember. DataMember macht hier keinen Sinn.
Wenn du ToString() überschrieben hast, brauchst du nichtmal DisplayMember.

FTR: DataMember benutzt man, wenn die Klasse der DataSource selbst wieder Eigenschaften besitzt, die ein Container ist.
Auf die Art kannst du einfach Master-Detail-Beziehungen abbilden, aber hier ist das natürlich absoluter Käse. (Oder erkennt SWF hier das IEnumerable von String und gibt dir die einzelnen Chars? :mrgreen:
Nachtrag2: Gerade getestet -> Ja! :lol: (gleich'n screenie angehängt :mrgreen: )

Zitat:

Anscheinend sind die WinForms Controls nicht so ganz trivial, im Web-Bereich hab ich da nie wirklich Probleme mit gehabt... Was hab ich denn hier vergessen? Bei der Grid reicht das hier vollkommen aus. :gruebel:

Naja, eigentlich gibt es kein wirkliches DataBinding in ASPX. SWFs DataBinding ist schon ein sehr schniekes System. ;)

edit2: :shock: Boah, habe ich hier einen Kauderwelsch reineditiert... :freak:

[Phoenix]

Zitat:

Zitat von Elvis

Jetzt wäre natürlich noch schön zu wissen was da drin steht.
Ist RoleList auch wirklich von List<T> oder BindingList<T> abgeleitet, bzw implementiert es generische Interfaces?

RoleList leitet von ProjectBaseList ab und die ist von System.Collections.CollectionBase abgeleitet.
Es ist interessanterweise die gleiche Liste, die im anderen Form einwandfrei an der Grid hängt und da alles tut was sie soll.

Zitat:

Zitat von Elvis

Das Erben von einer generischen Liste (welche BCL-Liste auch immer) sollte das Problem beseitigen.

Wie gesagt: Es ist im Herzen eine CollectionBase, also daran liegts schonmal nicht.

Zitat:

Zitat von Elvis

Einfach DataSource besetzen und DisplayMember. DataMember macht hier keinen Sinn.
Wenn du ToString() überschrieben hast, brauchst du nichtmal DisplayMember.

Nein, ToString() hab ich auf dem Item (das ist mit einem Zwischenschritt von Object abgleitet) nicht überschrieben. Macht an der Stelle auch keinen Sinn, das ist ne Fachklasse, die braucht sowas ned ;-)

ABER: Wenn ich nur:

Code:

            // Get available roles for Selection list:
            _rightsRoleList = new RoleList();
            _rightsRoleList.Init();

            // put roles to source
            _srcRightsRoleList.DataSource = _rightsRoleList;
            Int32 Testcount = _srcRightsRoleList.List.Count;

            // put source to ListBox
            lstBoxRightsRoles.DisplayMember = "Name";
            lstBoxRightsRoles.DataSource = _rightsRoleList;

Mache hilft das auch nicht.

Zitat:

Zitat von Elvis

FTR: DataMember benutzt man, wenn die Klasse der DataSource selbst wieder Eigenschaften besitzt, die ein Container ist.
Auf die Art kannst du einfach Master-Detail-Beziehungen abbilden, aber hier ist das natürlich absoluter Käse. (Oder erkennt SWF hier das IEnumerable von String und gibt dir die einzelnen Chars? :mrgreen:
Nachtrag2: Gerade getestet -> Ja! :lol: (gleich'n screenie angehängt :mrgreen: )

In dem Fall hätte ich Konsequenterweise bei dem oben geposteten Code nicht die Rollennamen in der Liste haben müssen sondern die einzelnen Chars des ersten Rollennamen. Aber auch das war nicht der Fall: Die Box ist komplett leer.

[Phoenix]

Zitat:

Zitat von Elvis

Jetzt wäre natürlich noch schön zu wissen was da drin steht.

Äh... ahso. Ja. Screenie was da drinsteht im Anhang ;-)

[Elvis]

In dem Screenie habe ich ein class diagram gezeigt mit der Bleistiftklasse. Bei mir gates. ;)
Jetzt gibt es mehrere Möglichkeiten und ich tippe immer noch auf meinen ersten Verdacht: der BindingContext bekommt keine komplette PropertyCollection.
Irgendwo down the road wird eine der Vorgängercontainerklassen ITypedList implementieren und den TypeDescriptor von Object oder eines Vorgängers von Role benutzen. Dadurch würden dir natürlich die Properties fehlen, bzw sie würden nicht mehr richtig ankommen.
Es scheint dass du den Code von Role oder RoleList + Vorfahren nicht so einfach rausrücken willst. ;)
Ich kann dir ein NDA anbieten und du mailst mir den nötigen Code, da das mit einer Fernwartung ohne Code nix wird.
Die zweite und definitiv schniekeste Lösung wäre, wenn du auf CollectionBase verzichtest und deine Container on Grund auf generisch machst.
Du hättest also ProjectBaseList<T> : List<T> und RoleList : ProjectBaseList<Role>.
Da ProjectBaseList nicht umsonst existiert und du darin ganz sicher auf Eigenschaften des Vorgängers deiner ElementKlasse zugreifst, müsstest du sie deshalb so deklarieren:

Code:

public class ProjectBaseList<T> : List<T>
  where T: IVorgänger, class
{
...
}

Ich nahm hier ein Interface.

• Erstens hast du so ein paar Vorteile...
  1. Kein Vererbungszwang
  2. virtual dispatch für jeden Call wird auf interface dispatch einmal pro Instanz, bzw einmal für jeden Element typen (falls dieser sealed ist) reduziert.
  Wirklich gut ist der erste Punkt, der zweite bewirkt "nur" schnelleren Code nachdem der Jitter/NGEN drücbergerödelt ist. ;)
  
• zweitens mag ich Interfaces einfach lieber. :mrgreen:

[Phoenix]

Du hast Recht, den Code kann ich hier ned posten, aber Du bekommst morgen früh mal Post :)

Die Baselist genereisch machen.. wär ne nette Idee, aber das Objekt ist ziemlich spezifisch weil es die Datenbankzugriffe für die Items erledigt. Will heissen die spezifische Collection kennt die Programmlogik für die Erstellung der spezifischen Objekte und der Liste selber, und damit ist da nix generisches rauszuziehen, zumal die einzelnen Objekte u.U. recht komplex sind. Naja, diese Rolle hier nicht, aber manch andere schon.

Zudem kann ich von dem Aufbau nicht weg. Der ist im Projekt vorgegeben und ich kann nicht davon abweichen.

Was mich immer noch wundert: Genau diese Objekte funktionieren einwandfrei an einer Grid.