DataGridView - Daten von SubClass darstellen

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 4 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    DataGridView - Daten von SubClass darstellen

    Guten Tag zusammen!

    Nehmen wir als Beispiel folgenden Code:
    Spoiler anzeigen

    VB.NET-Quellcode

    1. Option Strict On
    2. Imports System.ComponentModel
    3. Public Class Form1
    4. Private ts As New BindingList(Of t)
    5. Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    6. ts.Add(New t(0, "Null", New Kategorie(0, "Kategorie Null")))
    7. ts.Add(New t(1, "Eins", New Kategorie(1, "Kategorie Eins")))
    8. DataGridView1.DataSource = ts
    9. ts(0).Kategorie.getData(New Kategorie(2, "Geändert"))
    10. End Sub
    11. End Class
    12. Public Class t
    13. Implements INotifyPropertyChanged
    14. Private _ID As String
    15. Public Property ID() As String
    16. Get
    17. Return _ID
    18. End Get
    19. Set(ByVal value As String)
    20. _ID = value
    21. RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs("ID"))
    22. End Set
    23. End Property
    24. Private _Name As String
    25. Public Property Name() As String
    26. Get
    27. Return _Name
    28. End Get
    29. Set(ByVal value As String)
    30. _Name = value
    31. RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs("Name"))
    32. End Set
    33. End Property
    34. Private _Kategorie As New Kategorie
    35. Public Property Kategorie() As Kategorie
    36. Get
    37. Return _Kategorie
    38. End Get
    39. Set(ByVal value As Kategorie)
    40. _Kategorie = value
    41. RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs("Kategorie"))
    42. End Set
    43. End Property
    44. Sub New()
    45. End Sub
    46. Sub New(i As Integer, n As String, k As Kategorie)
    47. ID = i.ToString()
    48. Name = n
    49. Kategorie.getData(k)
    50. End Sub
    51. Public Event PropertyChanged(sender As Object, e As PropertyChangedEventArgs) Implements INotifyPropertyChanged.PropertyChanged
    52. End Class
    53. Public Class Kategorie
    54. Implements INotifyPropertyChanged
    55. Private _ID As String
    56. Public Property ID() As String
    57. Get
    58. Return _ID
    59. End Get
    60. Set(ByVal value As String)
    61. _ID = value
    62. RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs("ID"))
    63. End Set
    64. End Property
    65. Private _Name As String
    66. Public Property Name() As String
    67. Get
    68. Return _Name
    69. End Get
    70. Set(ByVal value As String)
    71. _Name = value
    72. RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs("Name"))
    73. End Set
    74. End Property
    75. Sub New()
    76. End Sub
    77. Sub New(i As Integer, n As String)
    78. ID = i.ToString()
    79. Name = n
    80. End Sub
    81. Public Sub getData(k As Kategorie)
    82. ID = k.ID
    83. Name = k.Name
    84. End Sub
    85. Public Overrides Function ToString() As String
    86. Return _Name
    87. End Function
    88. Public Event PropertyChanged(sender As Object, e As PropertyChangedEventArgs) Implements INotifyPropertyChanged.PropertyChanged
    89. End Class


    Dort habe wir eine Hauptklasse namens "t" und eine SubClass namens "Kategorie". Um diese ganze Sache nun in einem Datagridview darzustellen, habe ich der Hauptklasse bisher immer eine ReadOnly Property gegeben, die die Bezeichnung der SubClass ausgibt.
    Nun habe ich es mal so getestet, die ToString() Funktion der SubClass zu überschreiben, sodass diese den Namen wiedergibt.

    Ist das so okay, oder meint ihr das sollte man so besser nicht machen?

    Kleine Anmerkung:
    Das Datagridview soll nur zur Darstellung dienen, dort soll der User nichts editieren können, sonst würde auch (glaube ich) bei der ToString()-Version ein Fehler wegen falschem Datentyps kommen. (Also beim Klick ins Datagridview/hinzufügen von Rows).
    Polling is trolling!

    Achtung: Ich habe die komische Angewohnheit, simple Dinge zu verkomplizieren..

    Rootbob91 schrieb:

    sodass diese den Namen wiedergibt.
    Die ToString-Funktion wird aufgerufen, wenn Du eine Variable überwachst. Da lässt sich ne ganze Menge reinpacken und wird dann in einer Zeile angezeigt.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Das Datenmodell haut nicht hin.
    Bei dir hat jedes t seine eigene Kategorie, das macht bei 100 ts 100 Kategorien, und das ist Crap.

    Ich denke, du solltest relational denken, und typisiertes Dataset benutzen - damit kann man ein Kategorie-System schlüssig modellieren.
    Selbstgebastelte Klassen, und seien sie noch so OOP langen da nicht mehr hin.

    das 4Views-Tut kennste vermutlich, oder?


    Btw: Wer kommt auf die irre Idee, eine Klasse mit "t" zu benennen?

    "T" ist der Standard-Name generischer Typ-Parameter - das sollteman unbedingt von konkreten Klassen trennen.
    Ach mensch EDR, war doch nur als Beispiel ;).. Ich nenne meine Klassen ganz bestimmt nicht so xD..
    Letzteres weiß ich auch.

    Ich bin ganz ehrlich, ich hab mir die Dataset-Geschichte jetzt schon ein paar mal angeschaut.
    Neues DataSet adden und designen (mit Schlüsseln und co) ist kein Problem, aber dann vergeht mir irgendwie die Lust da weiter zu machen, kann ich nicht beschreiben^^..

    Verstehe noch nicht wie ich das Dataset dann befüllt bekomme, also wie ich praktisch die Klasse/bzw. deren einzelner Objekte da rein bekomme und dann vlt. auch dessen Methoden aufrufe.

    Vlt. wage ich mich da in den nächsten Tagen nochmal dran, aber ist immer so Kacke wieder bei 0 anzufangen und sich umzugewöhnen :/..
    Polling is trolling!

    Achtung: Ich habe die komische Angewohnheit, simple Dinge zu verkomplizieren..
    Zum Zufügen werden doch hervorragend geeignete Add-Methoden generiert - ist doch alles im 4-Views-Tut durchgekaut und vorgemacht.
    Einzige Gefahr ist, dass man nicht schnallt, die generierten Add-Methoden auch zu benutzen, und stattdessen die untypisierten Add-Methoden nimmt, und damit wieder ins untypisierte Paradigma zurückfällt.

    PS: ich nenne Dummi-Klassen eben "Dummy" oder "Item" ;) .