Button Funktion über mehre Forms nutzen...

Hallo !

Ich will einen Button über insgesamt sieben Forms mit immer der selben Funktion nutzen können. Jetzt will ich für den Button nur einmal eine Anweisung schreiben, die eine Aktion auslöst.

Wie kann ich jetzt den Button am besten und cleversten verbinden, damit ich den Programmieraufwand am geringsten halte?

Besten Dank für Eure Hilfe..

Gruss

eine form mit dem button erstellen und alle anderen forms davon erben lassen.

oder falls die Basisklasse der Forms nicht gleich sein kann / darf einfach den button als eigenes control erstellen und dann auf den jeweiligen Container / Form legen

Hallo macke_a,

was soll denn der Button für eine Funktion ermöglichen?

Wenn es eine Funktion ist, die überhaupt nichts mit der aktuellen Form zu tun hat, dann solltest Du die Funktionalität sowieso in einer eigenen Klasse auslagern und die bei einem Klick dann einfach aufrufen.

Wenn es Fensterbezogen etwas erledigen soll, dann halte ich JAck30lena's Vorschlag für geeignet.

Grüße
Norman-Timo

oder falls die Basisklasse der Forms nicht gleich sein kann / darf einfach den button als eigenes control erstellen und dann auf den jeweiligen Container / Form legen

dir ist aber schon bewusst das form immer eine gemeinsame basisklasse hat? und das es keinen unterschied machen würde, wenn er eine form erstellst von dem alle die den button brauchen einfach nur erben?

[Edit]
Es ist zu früh am Morgen, sorry Verwechslung 🤔

dir ist aber schon bewusst das form immer eine gemeinsame basisklasse hat? und das es keinen unterschied machen würde, wenn er eine form erstellst von dem alle die den button brauchen einfach nur erben?

Das ist ein bischen voreilig.
Er kann ja den Code der seine Logik abbildet nicht in System.Windows.Forms.Form ablegen. Insofern reicht ihm nicht die Basis aller Forms.

Entscheidend ist wie seine Logik aussieht und worrauf sie sich bezieht. Ist sie spezifisch zu einer bestimmten "FormArt" sollte der Aufruf des Codes Form Spezifisch vererbert werden.

Ist die Logik eher spezifisch zu dem Button sollte es in den Button.
Zu viel Logik in eine übergeordnete Instanz sorgt für zu viele feste Bindungen welche unnötig die Komplexität in die höhe treiben.

Braucht man z.Bsp. auf 3 Masken einen Button der einfach immer nur eine MessageBox hoch bringt würde ich das nicht in die Form liegen. Vielleicht haben diese 3 Masken ja auch gar nichts mit einander zu tun und nach System.Windows.Forms.Form keine gemeinsame basisklasse mehr.

Geht es aber z.Bsp. darum dass er eine Bearbeitungsform hat welche einen Speichernbutton hat so sollte man diesen IMO schon auf der Basis Bearbeitungsform legen damit alle Datenforms einen Speichernbutton haben.

Worauf ich hinaus will ist, dass man das eben nicht so pauschalisieren kann und man das Szenario beachten muss,welches bishier noch nicht genannt wurde

Das ist ein bischen voreilig.

da bin ich anderer meinung weil dieses szenario eigendlich bekannt ist. ok wir kennen es nicht im absoluten detail aber wenn wir vor jeder antwort danach vorgenen würden, dann müsste jeder themenersteller seine solution mit hochladen und jder der antwortet immer erst die komplette solution durchschauen.

Zu viel Logik in eine übergeordnete Instanz sorgt für zu viele feste Bindungen welche unnötig die Komplexität in die höhe treiben.

richtig aber das nennt man den gemeinsamen nenner und wenn es 7 foms gibt die einen button bruachen der immer das selbe macht dann ist das standardverfahren eine form zu machen, die diesen button besitzt und dessen ablauf dort festgelegt ist. anschließend erben alle forms, die diesen button bruachen von der erstellen form.

Braucht man z.Bsp. auf 3 Masken einen Button der einfach immer nur eine MessageBox hoch bringt würde ich das nicht in die Form liegen.

ich schon, da eine messagebox ein dialog ist und es gibt einfach ncihts nervigeres als irgendwelche subcontrols die messageboxen werfen, da man anschließend extra logik verpacken muss um eben dies in bestimmten fällen vermeiden zu können.

da bin ich anderer meinung weil dieses szenario eigendlich bekannt ist

Genau das denke ich nicht s.u.
Du setzt ein paar dinge implizit vorraus über die hier nichts steht.

ok wir kennen es nicht im absoluten detail aber wenn wir vor jeder antwort danach vorgenen würden, dann müsste jeder themenersteller seine solution mit hochladen und jder der antwortet immer erst die komplette solution durchschauen.

das behauptet ja auch keiner. Es ist ja kompeltt egal wie seine Form aussieht etc. Es geht um die logischen Zusammenhänge.

richtig aber das nennt man den gemeinsamen nenner und wenn es 7 foms gibt die einen button bruachen der immer das selbe macht dann ist das standardverfahren eine form zu machen, die diesen button besitzt und dessen ablauf dort festgelegt ist. anschließend erben alle forms, die diesen button bruachen von der erstellen form.

Woher weißt du das?

Vielleicht hat er 60 forms und davon brauchen nur 7 den Button. Ist dann der gemeinsame Nenner nicht eher , das nicht haben das buttons ?

Vielleicht sieht die Hierachie ja so aus:

[PRE]
     System.Windows.Forms.Form
       |             |
 DatenForm      3D- Anzeige forum
     |                 | 
13 ableitungen      10 Ableitungen
    |                    |
6 Stück mit Button    1 mit Button[/PRE]

Vielleicht brauchen nun 6 Datenforms und 1 3d Form den Button ?
Dann eine Gemeinsame Klassenbasis schaffen wäre kontrakproduktiv . Gerade dein nachfolgendes Argument gibt mir da recht:

es gibt einfach ncihts nervigeres als irgendwelche subcontrols die messageboxen werfen, da man anschließend extra logik verpacken muss um eben dies in bestimmten fällen vermeiden zu können.

So müsste man nämlich in obigen Beispielen in 16 von 26 Fällen eine Ausnahme programmieren, datt einmal die Logik in einen Button packen.

Wie ich geschrieben habe muss es nicht falsch sein die Logik in die Form zu packen. Denn wenn die Forms sich sinnvoll auf eine Basis bringen lassen und die Logik somit Form spezifisch ist macht das mehr sinn, aber genau dafür fehlen die entscheidenden Informationen.

Letztendlich zu bewerten welches in dieser Situation die bessere Lösung ist ist mit den gegebenen Informationen nicht möglich.
Und nichts anderes habe ich vorher gepostet

wenn ich ale möglochen architekturvarianten in betracht ziehen würde bevor ich einen post schreibe, weil der autor seine nicht ins detail erläutert hat, dann würde ich keinen einzigen post mehr schreiben.

normalerweise nehme ich den einfachsten fall an:

form1:Form
form2:Form
form3:Form
form4:Form
form5:Form
form6:Form
form7:Form

soviel zur architektur. daraufhin meine empfehlung, eine gemeinsame basis zu bilden. wenn das nicht geht, dann melden sich die leute schon und schreiben: "ja das geht leider nciht da....." und darauf bauen dann andere empfehlungen auf. wenn ich jetzt jedem zuerst schreibe, er solle doch bitte erst ein klassendiagramm posten, damit ich sehe ob ein vorschlag der im standardfall ausreicht, auch sicherlich zutrifft, ... naja.

mir ist schon klar das man immer differenzieren musss und das es immer ausnahmen gibt aber wenn ncihts spezielles vom autor erwähnt wird, dann nehme ich den einfachsten fall an und dann ist der autor ggf. selber schuld wenn er für sein spezielles problem unpassende lösungen bekommt, da er eben diese spezialtäten die wichtig sind nciht erwähnt hat. außerdem weiß man nie wie groß das wissen des autors in sachen programmierung ist. demnach gehe ich von der art der fragestellung immer vom simpelsten prinzip aus.

back to topic:
also lieber macke_a, wenn deine erchitektur so aussieht wie ich in diesem post angenommen habe, dann empfehle ich dir eine basisform zu kreieren, die diesen button samt logik beinhaltet.

ich hoffe das das jetzt für alle beteiligten korrekt ausgedrückt ist.

prinzipiell bin ich deiner Meinung ich finde nur dass es nicht schade einfache Varianten die ggf. auch passen könnten direkt mit vorzuschlagen 🙂

Hallo !
Danke für Eure Beiträge...

Insgesamt habe ich sieben Forms. Jede dieser Forms hat immer den selben Button und immer die gleiche Funktion! Beim Button Druck schalte ich ein Relais, das wiederum einen Lautsprecher aktiviert / deaktiviert.

In meiner Form1 würde ich die Funktion beschreiben wollen um diese in den nächsten sechs Forms nutzen zu können.

Sollte ich die Funktion, an alle meine anderen sechs Froms vereben, so muss ich aber jedesmal für meine Form, wiederum eine kurze Routine zu dem Button, der meine Funktion aus der Form1 aufruft, schreiben.

Kann man so etwas nicht schöner programmieren, zum Beispiels mittels Databinding oder ähnliches?

Am liebsten würde ich den anderen sechs Forms, eine direkte Quelle zuordnen, wo diese Zugriff auf meine Funktion haben, die in Form1 steht!

Ingesammt nutze ich sogar vier Buttons, die auf allen sieben Forms auftauchen! Somit wird der Programmieraufwand erheblich größer und die Übersicht läßt zu wünschen über!

Vielleicht könnt Ihr mir noch einmal weiterhelfen??

Gruss macke_a

so wie ich bereits mehrere male beschrieb kannst du dein problem lösen.

Hallo nochmal,

ich muss gestehen, dass ich auch eher in die Richtung von Haggy gehen würde. Ich würde es zunächst auch differenzierter sehen.

Selbst in dem Fall von macke_a würde ich es in Erwägung ziehen die Logik des "Relais schalten" nicht lieber in eine Business-Logic Klasse zu stecken, um dann in allen Buttons einen Aufruf daraus zu machen.

Klar kann man auch eine Basis-Form entwickeln, die einen Button und den Aufruf in die Bussiness-Logic implementiert, von der dann andere Forms erben können.

Wir reden aber hier von einem erhöhtem Aufwand im Minutenbereich, und deshalb wäre es mir im Stile von Haggy schon eine Überlegung wert, die Loslösung von Basisklassen in Betracht zu ziehen.

Es hat immer Vor- und Nachteile und ist im Grunde auch eine Designtechnische Geschmacksfrage, die weder schwarz noch weiß kennt. Das eine hat den Vorteil, dass man nicht per Konvention dran denken muss einen bestimmten Business-Logic Aufruf zu machen, das andere bedeutet, dass man im Nachhinein keine "Ausnahmen" oder Überschreibungen programmieren muss, wenn doch ein geändertes Verhalten gewünscht ist...

Beides ist legitim, und so lange sowieso nur einer dran programmiert wahrscheinlich eh Wurscht 😉

Grüße
Norman-Timo