Suchergebnisse

hmm - ich sehe eine eklatante Verwechslungsgefahr, und eine bereits eingetretene Verwechslung bzw. überhaupt fehlende Unterscheidung- Zitat: „"Form1" habe ich hier in "Form" umbenannt.“Also eine Klasse "Form" zu nennen, wos doch schon die Klasse Form gibt, und dein Form erbt auch noch vom Form - das ist so dermaßen zwingend auf Verwechslung hin-programmiert, dass man glaub meiner Beschreibung davon kaum noch folgen kann. - VB.NET-Quellcode (1 Zeile)Hier verwendest du die Klasse Form, als sei es …

naja, das Tut soll ja wohl weitergehen, und ich bin gespannt, wie man iwann mal die Szenen umschalten können wird. Um so eine Entkopplung zu erreichen muss man zw. den beiden Architektur-Pattern "gemeinsame Basisklasse" und "gemeinsames Interface" wählen - hat jeweils Vor- und Nachteile, und hier ist halt "gemeinsame Basisklasse" gewählt.

Aber du sagst es doch selber:Zitat von J-F: „Zuerst müssen wir noch eine Variable erstellen um den Code der Klassen ausführen zu können.“ Das ist eine ganz allgemein richtige Feststellung, gültig für jede Klasse, und also auch für die Form-KlasseVB.NET-Quellcode (2 Zeilen) VB.NET-Quellcode (1 Zeile)geht leider auch, und scheint bequem. Aber tatsächlich verhindert es Unterscheidungsfähigkeit. Das geht auch nur mit Erben der Form-Klasse, für alle anneren Klassen gilt der von dir selbst geprägte Sa…

prinzipiell schon. Am wichtigsten ist halt, du weißt was du tust. Und wenn du dieses DefaultForm-Feature nutzen willst, kein Threading verwendest, und deine Forms nicht in einer Klassenbibliothek erstellst, dann geeeht das auch. Wichtig ist halt, man weiß was man tut, und da habich bei solchen Konstruktionen einen anneren Eindruck. Und du sagst halt selbst: Zitat: „der Schlüssel zu einem erfolgreichen Spiel ist ein guter Aufbau und eine gute Struktur.“Von dem her würdich eher die Finger von dies…