Problem mit OOP beim DataGridView

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

Es gibt 22 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Problem mit OOP beim DataGridView

    Ich verwende in meinem Projekt ein DataGridView.

    Um es meinen Wünschen anzupassen, erbe ich in meinem Projekt ein DataGridView (das heißt jetzt A) und baue einige kleine Sachen ein.
    Weil ich das DataGridView A mit weiteren aber unterschiedlichen Eigenschaften ausstatten möchte, erbe ich von A und baue ins neue DataGridView B weitere Sachen ein, u.a. werden dort im VS Designer auch die Spalten angelegt.
    Später sollen noch DataGridView C und D ebenfalls von A erben. Das DataGridView B wird dann in das Projektfenster von meinem Projekt reingezogen. So weit klappt es auch alles.

    Leider bauen sich dann wie von Zauberhand nach einem Compilerdurchlauf weitere Spalten von selbst ein.

    Ich hoffe ich konnte mein Problem verständlich umschreiben und das sich jemand findet der mit zeigt wo mein Denk- bzw. Verständisfehler liegt.
    Aktuelles Projekt: Z80 Disassembler für Schneider/Amstrad CPC :love:

    oobdoo schrieb:

    Was denn davon alles?
    Lösche zunächst das verunglückte Zitat.
    Poste so viel, dass Dein Effekt reproduziert wird.
    Teste dies ggf. in einem separaten Projekt.
    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!

    Ich konnte das Problem etwas weiter Einkreisen. Sobald ich mein DGV ins Hauptformular einfüge, dann werden auch weitere Spalten eingebaut.

    Anbei zwei Bilder aus dem Projekt:

    Mein DataGridView in welchem ich die Spalten über den Designer eingefügt habe.


    Das im Projektformular eingefügte DataGridView im Designer, welcher von sich aus nochmal die Spalten einbaut.


    Hier ein ZIP mit einem Testprojekt, welches das gleiche Verhalten zeigt sobald ich F5 drücke.

    DataGridTest.zip

    Wobei ich immer noch nicht verstanden habe, warum die zusätzlichen Spalten manchmal im Designer sichtbar sind dann manchmal erste nach dem F5 drücken.

    Als Ursache vermute ich ein falsches Vorgehen wenn ich von einem Steuerelement erben will.

    Bisher gehe ich immer so vor:
    • Projektmappen-Explorer
    • Hinzufügen > Benutzersteuerelement
    • Änderung im UserControl.Designer.vb durchführen, also von Inherits System.Windows.Forms.UserControl nach Inherits System.Windows.Forms.DataGridView


    Dann meckert VS innerhalb von

    VB.NET-Quellcode

    1. Private Sub InitializeComponent()
    2. components = New System.ComponentModel.Container()
    3. Me.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font
    4. End Sub


    Das Me.AutoScaleMode nehme ich dann immer raus.
    Aktuelles Projekt: Z80 Disassembler für Schneider/Amstrad CPC :love:

    Du fügst im TestGrid-Designer die Columns hinzu. Und in der Fom1.Designer.vb geschieht dies nochmal. Zu sehen immer dann, wenn der Form1-Designer geschlossen und wieder geöffnet wird, wenn Änderungen stattgefunden haben. Noch mehr zu sehen, wenn man TestGrid auf Form1 zieht. Form1-Designer schließt, wieder öffnet, TestGrid verschiebt, Form1-Designer schließt, wieder öffnet. Dann wurden noch mehr Columns hinzugefügt.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    oobdoo schrieb:

    Aber wie kann ich sowas zukünftig vermeiden?
    Indem Du Dir von uns helfen lässt und den Code ohne Binaries als ZIP anhängst.
    Die bunten Bilder, die Du da angehängt hast, sind nicht hildreich, wie müssten schon mal das Projekt haben.
    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!

    Öhm ... @RodFromGermany: Das Projekt ist in Post#5 hinterlegt.
    Da die Spalten im Hauptformular automatisch hinzugefügt werden, ist da wohl nix zu machen. Bleibt nur die Möglichkeit, es in der TestGrid-Designer-Datei zu unterlassen Spalten hinzuzufügen.
    btw: Gibt es einen Grund für die 2 User-CE-Dateien? Denn Es reicht ja, wenn man in eine leere CodeDatei reinschreibt:

    VB.NET-Quellcode

    1. Public Class DgvA : Inherits DataGridView
    3. Private TProperty As Integer
    5. Public Property TestProperty() As Integer
    6. Get
    7. Return TProperty
    8. End Get
    9. Set(ByVal Test As Integer)
    10. TProperty = Test
    11. End Set
    12. End Property
    14. End Class

    Und dann das Ganze kompiliert. Dann taucht in der ToolBox auch das 1. DGV auf. Das Gleiche kannst Du mit DGV2 machen. Ok, Dein Problem ist dadurch nicht gelöst. Aber wenn Du den User-CE-Designer eh nicht nutzt, wird es um einiges kompakter.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    VaporiZed schrieb:

    Das Projekt ist in Post#5 hinterlegt.

    @oobdoo Sorry, da in der Mitte des Posts ist es mir durch die Lappen gerutscht.
    ======================
    @oobdoo Du hast einmal 3 Spalten im TestGrid,
    Du hast 3 weitere Spalten in Form1.
    Nimm die Spalten imn TestGrid raus und feddich. :thumbsup:
    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!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RodFromGermany“ ()

    Naja, nee, so einfach ist das nicht. Wenn die im Testgrid rausgenommen werden, verschwinden die auch früher oder später im Formular, z.B. wenn man das aktuelle TestGrid-CE löscht und ein neues draufhaut. Warum auch immer fügt die From1.Designer.vb jene Columns hinzu, die in der Designer.vb bzw. im TestGrid-Konstruktor schon hinzugefügt wurden.
    ##########
    Das mit der User-CE-Datei nehm ich zurück. Hab grad gesehen, dass VS da selber nen CE-Designer dazuschaltet.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    oobdoo schrieb:

    Um es meinen Wünschen anzupassen, erbe ich in meinem Projekt ein DataGridView (das heißt jetzt A) und baue einige kleine Sachen ein.
    Das ist eine höchst anfällige (und unnötige) Vorgehensweise.
    Selbstgebastelte Controls müssen sich im Designer verhalten, nach den Regeln, die dort herrschen (und die kaum jemand vollständig kennt).
    Da kommt dann schnell sowas bei raus, dass der Designer unerwünschte Zusatz-Spalten hinzu-generiert.

    Ich empfehle, DGV nicht zu beerben, sondern die Gestaltung im Designer abzuhandeln.
    Ansätze dazu siehste glaub in vier Views-Videos
    Aber wennde dich mit den Designer-Dialogen noch mehr beschäftigst, geht dir schnell auf, wie unerhört umfangreich die Gestaltungsmöglichkeiten sind.
    Wie gesagt: Vom Erben die Finger lassen.

    Zur Not kannste auch Methoden schreiben, die ein DGV empfangen und gestalten.
    Ist sogar weniger Code als es zu beerben, und wie gesagt: solche Methoden tun nur was sie tun, und verhalten sich nicht im Designer...

    ErfinderDesRades schrieb:

    oobdoo schrieb:

    Um es meinen Wünschen anzupassen, erbe ich in meinem Projekt ein DataGridView (das heißt jetzt A) und baue einige kleine Sachen ein.
    Das ist eine höchst anfällige (und unnötige) Vorgehensweise.
    Selbstgebastelte Controls müssen sich im Designer verhalten, nach den Regeln, die dort herrschen (und die kaum jemand vollständig kennt).
    Da kommt dann schnell sowas bei raus, dass der Designer unerwünschte Zusatz-Spalten hinzu-generiert.

    Ich empfehle, DGV nicht zu beerben, sondern die Gestaltung im Designer abzuhandeln.

    Ok, dann habe ich einen falschen Ansatz verfolgt. Aber widerspricht das nicht dem Konzept von OOP?
    Ich dachte ich könnte mir so aus einen DGV einen Baustein zimmern, den ich überall verwenden und ggf. weiter erweitern kann.
    Aktuelles Projekt: Z80 Disassembler für Schneider/Amstrad CPC :love:

    oobdoo schrieb:

    Aber widerspricht das nicht dem Konzept von OOP?
    Nicht bei solch komplexen Controls wie dem DGV.
    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!

    Jetzt dachte ich, ich wäre ganz schlau wenn ich das DGV in ein leeres Control einfüge, von diesem Control dann erbe um dort dann das DGV im Designer zu verändern.
    Das ist dann aber komplett gesperrt (auch wenn ich es auf PUBLIC ändere), im Gegensatz zu den anderen Steuerelementen.
    Ich seh schon, mir fehlt noch so einiges an Verständnis beim VB.net & Co. ||
    Aktuelles Projekt: Z80 Disassembler für Schneider/Amstrad CPC :love:

    oobdoo schrieb:

    fertige konfiguriertes DGV
    Da reicht es doch, diesem eine entsprechende DataTable als DataSource zuzuweisen.
    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!

    ErfinderDesRades schrieb:

    wat?
    In seinen Beispielen hat er einfach nur 3 Spalten eingetragen.
    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!