Microsoft Menüleiste nachprogrammieren

Palladin007 · Verfasst: Mi 27.07.16 14:56

Stell dir vor, du hast an einer Stelle entsprechende Properties, Methoden und Events für die verschiedenen Funktionen des Menüs
Ein anderer setzt das Menü um und nutzt dabei besagte Properties, Methoden und Events.

Du nutzt sie beim Verdraten ebenfalls
Wenn nun das Menü geändert wurde, dann funktionieren alte Funktionalitäten immer noch, ohne dass Du etwas tun musst.
So sollte es zumindest sein

Unter MVVM findest Du besagte Member im ViewModel
Bei MVC regelt das der Controler
Wenn Du unbedingt direkt mit dem Control quatschen willst, sollte zumindest das definieren, was es für Möglichkeiten hat.

Ralf Jansen · Verfasst: Mi 27.07.16 15:40

Zitat:

Bei einem Update wurde das Menü dann von der Person dementsprechend geändert und ich verdrahte das dann alles neu

Was ist für dich ein Update? Ein neuer Menüpunkt sollte bei einem Control ohne Änderung des Controls auskommen.

Csharp-programmierer · Verfasst: Fr 05.08.16 15:19

Fehler

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

Csharp-programmierer · Verfasst: Fr 05.08.16 15:30

Okay. Ich habe den Fehler gefunden

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

Csharp-programmierer · Verfasst: Fr 05.08.16 21:45

Aber eins verstehe ich immer nocht nicht. Was habt ihr gegen das verdrahten? Die DLL ist nun fertig und ich habe schon angefangen, das Hauptprojekt zu entwickeln. Dabei ist mir aufgefallen, dass ein Steuerelement gefehlt hat. Ich bin dann in die DLL gegangen, habe dieses Element hinzugefügt, kompilliert und dann dieses neue Element mit einer Methode verdrahtet. Das ging einwandfrei, besser als mit einem ToolStrip bsp (da ich diesen sonst immer genommen habe). Und ich habe im Quellcode auch viel mehr übersicht. Also wo ist hier der Haken?

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

private void VerdrahteAlleBenutzersteuerelemente()
        {
            this.uC_Mainmenue1.uc_Projekt.buttonText1.pictureBox1.Click += new EventHandler(Speichern);
        }

        #region"Verdrahtete Methoden WICHTIG"
       

        private void Speichern(object sender, EventArgs e)
        {
            MessageBox.Show("Speichern");
        }

Ich habe in diesem Beispiel natürlich die ganzen anderen Zeilen weggenommen, aber ich finde es viel übersichtlicher, auf dieser Art und Weise die Software zu warten. Können bei dem Verdrahten eventuell Fehler computerseitig auftreten, dass der PC etwas falsch verdrahtet, ansonsten sehe ICH keine Nachteile, das so zu machen.

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

Palladin007 · Verfasst: Fr 05.08.16 22:54

Den Nachteil hast Du schon im Snippet direkt mit drin: Du musst explizit anmerken, dass irgendetwas an anderer Stelle gebraucht wird.

Besser wäre, wenn es feste Eigenschaften gibt, die möglichst unabhängig von der eigentlichen Oberfläche sind und in einem Interface definiert werden.
Dort, wo Du das ganze brauchst, kennst Du nur das Interface, Du kannst damit arbeiten und brauchst dich nicht um die Umsetzung kümmern. Das kannst Du natürlich immer noch, aber Du musst niemandem sagen, wie diese Umsetzung auszusehen hat, Du sagst einfach nur kurz, wo das Interface zu finden ist und anhand dessen (und optimalerweise passende Doku-Kommentare dazu) kann es dann implementiert werden.

Außerdem hast Du so ein Interface, das klein, auf das Wesendliche zugeschnitten und übersichtlich ist. Du musst dich nicht mit Zeug drum herum beschäftigen, was für dich gar nicht von Bedeutung ist und hast damit auch nicht das Risiko, aus Versehen etwas falsch zu machen, weil ihr euch nicht richtig abgesprochen habt. Das Interface ist diese Absprache und das bleibt gleich, auch wenn sich die Implementierung vollständig ändert.

Und da ist auch gleich noch ein Vorteil: Du würdest direkt an den Controls hängen. Aber was ist, wenn dem Chef die Oberfläche nicht mehr gefällt? Er möchte die jetzt modernisiert haben, was vielleicht an manchen Stellen zu massiven Umbauten führt. Massig Controls fliegen raus, Andere kommen hinzu, alles anders eingestellt, etc. Du bist dann das arme Schwein, das alles nochmal machen darf, weil sich etwas geändert hat. Definierst Du ein Interface, was implementiert werden muss, dann musst Du idealerweise garnichts machen
Der Inhalt der Methode "VerdrahteAlleBenutzersteuerelemente" sieht sogar danach aus, dass diese Abhängkeiten über mehrere Ebenen gehen. Was ist denn nun, wenn Control A von B genutzt wird, was von C genutzt wird und so weiter? Ändert sich irgendein Control inerhalb dieser Kette, müssen im schlimmsten Fall alle anderen Stellen angefasst werden.

Außerdem werden erst durch Interfaces solche Spielereien wie das Facade-Pattern möglich, das Erweiterungen von Komponenten erlaubt ohne diese Komponenten zu ändern.
Das ist auch eine wichtige Regel, das Open-Closed-Principle: Offen für Erweiterungen aber geschlossen für Änderungen
So sollte eine Anwendung aussehen. Kommt ein neues Feature dazu, dann muss kaum bestehender Code geändert werden, es reicht die Umsetzung des Features und danach läuft die ganze Geschichte.

Klar, dass das so nie gelingt, da niemand alles einplanen kann, aber das ist das Ziel und wer Controls nutzt indem er deren internen Elemente direkt anspricht, der hat ganz schnell sehr empfindliche und unübersichtliche Abhängigkeiten und ist von diesem Ziel ganz weit entfernt.
Sollte es dennoch mal nötig und unvermeindlich sein, dass zwei verschiedene Controls direkt miteinander arbeiten müssen, dann kapsel diese Zugriffe zumindest in ein eigenes Control. Ein sinnvolles Beispiel dafür, das sich nicht anders und besser lösen lies, habe ich aber nich nie gesehen ...

Csharp-programmierer · Verfasst: Fr 05.08.16 23:22

Ah ich verstehe deine Antwort leider nur teilweise. Du redest von Interfaces, was müsste ich dann machen? Ein Interface hinzufügen oder die komplette DLL ändern? Bis jetzt (und ich habe mich darüber schonmal informiert), weiß ich nicht, zu was ein Interface zu gebrauchen ist

Und deswegen verstehe ich auch ca. 75% deiner Aussage ist. Was mir nun Bauchschmerzen macht, ist, dass ich nun 3 Wochen an der DLL Rum gebastelt habe und jetzt nicht nochmal alles komplett ändern muss.

PS: ab jz werde ich nur noch die DLL weiterentwickeln

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme