Laden...

Identische WinForm mehrfach verwenden

Erstellt von oehrle vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.514 Views
O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 13 Jahren
Identische WinForm mehrfach verwenden

Hallo, es war und ist meine Aufgabe, eine Verwaltung mehrer Produktionsgruppen zu erstellen, und die Planung der Gruppen in ihren Schichten (3-Schicht) darzustellen. Nun habe ich zuerst eine Produktionsgruppe erstellet, mit de ganzen datenbanken etc. usw und das funktioniert soweit alles. Dann habe ich mich an die zweite Produktionsgruppe gemacht. Ich habe alles in der DB dafür organisiert, habe dann die erste entworfenen FOrm einfach kopiert, und Kleinigkeiten angepasst.

Nun muss ich das System weiterpflegen, es kommt immer wieder etwas an Funktionalität hinzu. Außerdem muß ich noch zwei weitere Produktionsgruppen integrieren. Das heißt, wenn ich etwas ändere, muß ich das auch immer wieder in den anderen Forms ändern, bzw aus der Hauptform kopieren und in die anderen reinkopieren. Ist doch dann immer wieder viel act.

Ich habe nun auch schon eine statische Klasse erstellt, in den ich viele Methoden ausgelagert habe, und somit Änderungen nur zentral an einer Stelle ausführen muss.
Damit ich mir das Leben aber noch einfacher machen könnte, würde ich gerne im Konstruktoraufruf einer Form diese Form in die statische Klasse übergeben, damit ich dort dann auf die ganzen Controls usw. zugreifen und diese manipulieren kann. Das geht ja uach mit der Übergabe.

Nun aber zu folgendem Problem: Wenn ich jetzt 4 Forms habe, die alle aus der Hauptform resultieren, muß ich jedes mal abfragen, welche Form den gerade aktiv ist, um auf die betreffenden Controls usw. zuzugreifen können. Das ist einfach nervig, in jeder MEthode das abzufragen.
Gibt es eine Superklasse oder so etwas, wo ich sagen kann, das die WinForms immer auf die betreffende WinForm beziehen, aus der sie die Kopie sind?
Oder ist mein Ansatz komplett falsch?

F
10.010 Beiträge seit 2004
vor 13 Jahren

Ja, dein Ansatz ist vollkommen falsch.

Code kopieren und statische Klassen zeigen das dir sämtliche Grundlagen fehlen.
Schon mal überlegt die Grundlagen von OOP zu erlernen?

Oder willst du immer darauf angewiesen sein, das dir jemand aus diesem Forum deine Arbeit macht?

F
155 Beiträge seit 2009
vor 13 Jahren

"We better hurry up and start coding, there are going to be a lot of bugs to fix."

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 13 Jahren

Hallo FZelle,

OOP ist für mich nicht das Fremdwort. Nur hatte ich die Frage mit Forms vererben schon mal, da war die Antwort, einfach kopieren.

Nun sind meine FOrms alle identishc imAufbau, da sind drei Panels drauf und diese werden dynamisch je nach Abteilung aus einer anderen dataTable gefüllt. Die Dinge die in dien Panels dargestellt werden sind CHeckboxen.

Nun, wenn das dann total verkehrt ist gib mir einen Ansatz. Ich habe zuerst sozusagen eine Masterform erstellt, mit der ich mal alles getestet habe. Soll ich dann diese FOrm einfach vererben? Mach mir mal ein Vorschlag.

F
10.010 Beiträge seit 2004
vor 13 Jahren

Die Antwort auf die Frage in dem anderen Thread hast du dann aber komplett falsch verstanden.

Wenn du gleiche UI, mit verschiedenen Daten hast, dann werden nicht die UI Teile kopiert oder vererbt, sondern die Daten oder Businesslogik ausgetauscht.
Insofern musst du weder Kopieren noch vererben.

Sorry, aber wenn OOP kein Fremdwort für dich wäre, hättest du das schon verstanden.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 13 Jahren

Hi FZelle,

ich denke da kommen wir der Sache näher. Über ein #define definiere ich zu Beginn um welche Form dass es sich handelt. Dementsprechend wird im Code auch mit #if
geprüft, welche Projektabteilung der Form entspricht, darüber wird dann auch gesteuert welche Tabellen zu welcher Form (Projektabteilung) geladen werden.

Die Statische Klasse stellt Methoden bereit, die alle Forms benutzen (mit identischem Code). Das habe ich deswegen gemacht, wenn ich daran was änern muß, damit ich das nur einmal machen muss uch nicht in jede Form neu editieren muss, verstehst du mich da richtig?

Nun, ist meine Vorgeensweise so korrekt?
Wenn ja, wie ist das mit meiner Frage aus dem Eröffnungsbeitrag? Da müßte ich wohl au fjeden Fall vererben, wenn ich eine Basisklasse haben möchte, wo ich die andern FOrms immer wieder hineinstecke, oder?

F
10.010 Beiträge seit 2004
vor 13 Jahren

Nein, das hat nichts mit OOP zu tun, sondern ist ein italienisches Nudelgericht.

Du sollst hier nichts mit #define festlegen, sondern rein über die unterschiedlichen Daten, oder wenn bei unterschiedlichen Daten auch unterschiedlicher Code nötig ist über ein ViewModel/Presenter die Abarbeitung ändern.

PseudoCode


Klass DieseUI : IDieseUI

  public ISpezielleLogik SpezielleLogik{get;set;}
  public DataSet FormData{get;set;}

  protected override OnLoad(..)
  {
      SpezielleLogik.Initialize(this);
  }

  protected void WasAuchImmerButton_Click(..)
  {
      SpezielleLogik.BehandleWasAuchImmer();
  }
End Klass

Interface IDieseUI
{
  DataSet FormData{get;set;}

}

Interface  ISpezielleLogik
{
  IDieseUI m_View;
  void Initialize(IDieseUI view);
  void BehandleWasAuchImmer();
}

Du solltest dir wirklich mal OOP und dann mal etwas wie MVP anschauen.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 13 Jahren

Hi FZelle, du hast ja recht mit ital. Nudelgericht 😉

Ich werde mcih mit den Interfaces beschhäftigen, das ist wohl an der Zeit. Ich habe zwei Bücher von C#, werde da wieder mal die Nase reinstecken. Die Literatur dort erklärt zwar nicht so gut, werde aber ncoh im Internet rechrechieren, damit ich das fresse (hoffe ich doch).

F
10.010 Beiträge seit 2004
vor 13 Jahren

Nicht Nase Reinstecken, lesen 😉

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 13 Jahren

Hi FZelle, meine Nase juckt schon. Genial, das du mich ma richtig auf die Schnittstellen gehievt hast. Ich habe das zwar auch schon im Gallileo 2008 gelesen, konnte aber definitiv nicht soviel damit anfangen. Nun aber habe ich mal zwei abende darüber gelesen. Der Sinn wird mir klar, so eine Funktionalität habe ich schon öfters vermisst. damit können also die verschiedenen Klassen anpassbar und mit Gemeinsamkeiten beritgestellt werden.
Nun, mein Projekt ist erst mal ein bischen groß für diese erste VErsuche, aber ich werds probieren.
da ich bisher drei identische WinFoms hatte, und mit einem untyp. dataSet arbeite, werde ich erst mal das und die SQLAdapter über die Schnittstellen konfigurieren und an die dann gemeinsame Form übergeben.
Da ich 9 Tabellen habe und diese aber in den 3 Forms varieiren, werde ich das auch über die Schnittstellen dementsprechen konfigurieren.
Denkste die Vorgehensweise ist so OK??

F
10.010 Beiträge seit 2004
vor 13 Jahren

So pauschal, nein.
Was erwartest Du mit dem bisschen Info?

Es kann sein, das du nur eine Form, 2 Presenter und 9 DataTables brauchst.
Kann aber auch sein das Du eigentlich 9 Forms und 6 Presenter brauchst.

Wirklich kann man das nur sagen wenn es genauer geht.

Besser ist es statt in DataTables und Forms eher in UseCases zu denken.
Also was soll mit den Daten gemacht werden?
Gibt es Überschneidungen in den Funktionalitäten?

Nur weil man meint mit Vererbung arbeiten zu müssen, muss es nicht unbedingt sinnvoll sein.