For Each items As Object In Panel_AK_X.Controls
->
Vorallem da alles was du anschließend damit machst unabhängig vom Typ des Controls ist kannst du dir auch die beiden TypeOf überprüfungen sparen(die kosten relativ viel Zeit).
Ich weiß nicht wie gut VB.Net inzwischen ist aber evtl. geht auch das
das würde(also sowas geht halt in C#) dann den Typ für die items automatisch aus der Controls Collection deduzieren, ist aber somit von der Bedeutung her exakt dasselbe wie mein obiger Code.
Abgesehen davon sieht mir das nicht nach einem Sinnvollen aufbau aus.
Was genau macht denn dieser Code zum Beispiel? Ich sehe wenig Sinn davon Controls zu entfernen und dann auch noch so selektiv. Warum dann nicht alle in einem Panel sammeln und einfach das Panel löschen?
Warum haben die Controls alle Namen entsprechend der selektierten DGV Zeile? Erstellst du etwa für jeden Eintrag in der DGV zugehörige Controls? Wie sieht der Aufbau der Controls aus(Screenshot)?
Denn dynamisch Controls erzeugen ist oftmals nicht sehr sinnvoll. Vorallem da Controls in WinForms(ob dus glaubst oder nicht) ist jedes Control welches Events empfangen kann ein extra "Window" deshalb werden viele Controls auf einmal auch gerne langsam, weil für jedes Control viele Dinge gemacht werden, die du vmtl. gar nicht brauchst für diesen Fall. Ich denke hier muss evtl. ein UserControl her
Edit: Noch zu der Frage spätes binden selektiv zu zu lassen:
In C# gibt es dafür das dynamic-Keyword in Vb.Net gibt es ein solches Äquivalent meines Wissens noch nicht. In VB.Net kann man für ein einzelnes Dokument mittels Option Strict Off spätes binden zu lassen.
Aber ich sage es noch einmal das wirst du in sehr wenigen Fällen benötigen. Ich selbst habe es noch nie benötigt, da ich als Programmierer immer weiß was ich aufrufen will und auf welches Objekt und die dann entweder eine gemeinsame Basisklasse haben oder auch ein Objekt sind dessen struktur ich kenn, kann man mit Reflection die MethodInfo holen und mittels Expression API einen Aufruf erzeugen, der die nötige Konvertierung in den richtigen Typen vornimmt, da dann für jeden Aufruf für jedes Objekt nur der Code einmal generiert werden muss, ist das natürlich wesentlich performanter als dies bei jedem Aufruf aufs neue zu machen, was durch das späte Binden auf ähnliche weiße passiert.
Diesen letzten Abschnitt musst du auch nicht unbedingt verstehen, weil auch diese Dinge braucht man dann doch erst für ziemlich fortgeschrittene Sachen. Ich denke nicht, dass wir für dieses Projekt darauf zurückgreifen müssen.
Und wie du sehen kannst können wir die Fehler doch ziemlich leicht beheben. Wenn man halt mal ein Projekt mit Option Strict Off gemacht hat und sich nicht aus kennt hat man halt viel Arbeit, aber da du in Zukunft jedes Projekt mit Option Strict On machen wirst, wirst du diese Probleme in der Zukunft auch immer nur für den Moment und die einzelne Code Zeile haben und mit der Zeit Wissen was zu tun ist, bist du diese Fehler nicht mal mehr beim schreiben von Code auf dem Papier machst.
Denn solche Fehler werden ansonsten nur in Typ unsicheren Sprachen zugelassen die idR auch eher auf Duck-Typing bauen.
Java, C#, Vb.Net, C++ uvm. sind typsichere Sprachen(und gefallen mir in aller Regel auch besser, da man bei Typ-unsicheren Sprachen Code erst ausführen muss um Typ-Fehler zu finden, hier weiß man es zur Compiletime)
Ich wollte auch mal ne total überflüssige Signatur:
---Leer---
---Leer---
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „jvbsl“ ()