Zusätzlich würde ich vorschlagen, sich darüber zu informieren, was der Unterschied ist zwischen der "Form", die in Form von Quelltext in deinem Projekt enthalten ist und der Form, die später von deinem Programm auf den Bildschirm gebracht wird.
Das eine ist nämlich eine Klasse, und das andere ein Objekt. Zwei völlig unterschiedliche Dinge.
Leider hat Visual Basic das von Anfang an nicht so richtig getrennt. In den ersten Version IIRC sogar gar nicht. Spätestens in VB5 oder 6 konnte man es in seinem Programm auch logisch voneinander getrennt benutzen, aber meist hat man es trotzdem nicht genutzt, und diese Vermischung hat sich mindestens bis VS2010 durchgezogen.
Du nennst deine Fensterklasse "Startform" und sprichst sie in deinem Programm über den Klassennamen an, wodurch automatisch ein Objekt dieses Namens erstellt wird. Das ist schlecht, weil es - wie bei dir schön gesehen - zu Fehlannahmen verleitet, die später das Programm aus den Fugen reißen können, weil es "einfach nicht funktioniert".
Machs mit den Formen wie mit allen anderen Objekten auch: Erstell dir explizit dein Objekt aus der Fensterklasse und arbeite dann damit.
Die fortgeschrittene - in früheren Beiträgen dieses Threads schonmal angedeutete - Methode wäre, noch ein Interface zu definieren
und dieses Interface in deinen Form-Klassen zu implementieren, die alle so ein DataGridView gemeinsam haben:
Vergiss nicht, das Property Get für "GridView" zu implementieren, z.B. so:
Das wäre schonmal die halbe Miete. Ist aber noch nicht alles. Wenn man das Prinzip dahinter aber einmal begriffen hat, ist der Rest wirklich recht einfach und man wundert sich im Nachhinein, warum man es nicht von Anfang an so gemacht hat...
PS: SpaceyXs Signatur ist wirklich dringend zu empfehlen: Auch wenn "Option Strict On" auf den ersten Blick wie ein Klotz am Bein wirkt. Es hilft ungemein, 99% aller üblichen Fehler bereits während des Eintippens bzw. vor dem Kompilieren zu finden bzw. zu vermeiden.
Das eine ist nämlich eine Klasse, und das andere ein Objekt. Zwei völlig unterschiedliche Dinge.
Leider hat Visual Basic das von Anfang an nicht so richtig getrennt. In den ersten Version IIRC sogar gar nicht. Spätestens in VB5 oder 6 konnte man es in seinem Programm auch logisch voneinander getrennt benutzen, aber meist hat man es trotzdem nicht genutzt, und diese Vermischung hat sich mindestens bis VS2010 durchgezogen.
Du nennst deine Fensterklasse "Startform" und sprichst sie in deinem Programm über den Klassennamen an, wodurch automatisch ein Objekt dieses Namens erstellt wird. Das ist schlecht, weil es - wie bei dir schön gesehen - zu Fehlannahmen verleitet, die später das Programm aus den Fugen reißen können, weil es "einfach nicht funktioniert".
Machs mit den Formen wie mit allen anderen Objekten auch: Erstell dir explizit dein Objekt aus der Fensterklasse und arbeite dann damit.
Die fortgeschrittene - in früheren Beiträgen dieses Threads schonmal angedeutete - Methode wäre, noch ein Interface zu definieren
Vergiss nicht, das Property Get für "GridView" zu implementieren, z.B. so:
Das wäre schonmal die halbe Miete. Ist aber noch nicht alles. Wenn man das Prinzip dahinter aber einmal begriffen hat, ist der Rest wirklich recht einfach und man wundert sich im Nachhinein, warum man es nicht von Anfang an so gemacht hat...
PS: SpaceyXs Signatur ist wirklich dringend zu empfehlen: Auch wenn "Option Strict On" auf den ersten Blick wie ein Klotz am Bein wirkt. Es hilft ungemein, 99% aller üblichen Fehler bereits während des Eintippens bzw. vor dem Kompilieren zu finden bzw. zu vermeiden.
Ist dein Problem erledigt? -> Dann markiere das Thema bitte entsprechend.
Waren Beiträge dieser Diskussion dabei hilfreich? -> Dann klick dort jeweils auf den Hilfreich-Button.
Danke.
Waren Beiträge dieser Diskussion dabei hilfreich? -> Dann klick dort jeweils auf den Hilfreich-Button.
Danke.
