Entwickler-Ecke :: Thema anzeigen - Microsoft Menüleiste nachprogrammieren

Csharp-programmierer - Di 26.07.16 14:39
Titel: Microsoft Menüleiste nachprogrammieren

Hallo Community,
ihr kennt bestimmt alle die Menüleiste von den Microsoft Programmen. Diese Menüleiste würde ich sehr gern auch in meinen Projekten verwenden. In einem Betrieb, in dem ich Praktikum gemacht habe, haben sie auch die Menüleiste von den Microsoft Programmen gehabt.

Meine Frage: Wie kann ich in meinen Programmen auch so eine Menüleiste bauen, wie die von den Microsoft Programmen?

erfahrener Neuling - Di 26.07.16 15:10

Hallo,

ob man da ein bestimmtes Schema verwenden kann weiß ich nicht, aber du könntest einfach deine eigenen Controls kreieren ;)

Ich hatte mir zum Beispiel mal einen PictureButton gemacht, der ein Bild/Icon und darunter Text beinhaltet. Funktioniert dann ansich wie'n normaler Button. Das dann noch alles auf'm Panel schön gemacht und schon hatte ich die für mich passende Menuleiste.

Also DIY geht bei Design-Dingen eigntl immer gut

Gruß Julian

Christian S. - Di 26.07.16 15:17

Hallo,

such mal nach Suche bei Google

RIBBON CONTROLS WINFORMS. Da sollte man so einiges zu finden. Schau Dir auch mal an, unter welchen Lizenzbedingen man das verwenden darf. Ich meine, es gab da mal Einschränkungen :gruebel:

Grüße
Christian

erfahrener Neuling - Di 26.07.16 15:25

Wow cool. Hör und sehe grad zum 1. Mal von Ribbons :zustimm:
Vielen Dank dafür

Csharp-programmierer - Di 26.07.16 22:58

Okay, genau das ist, was ich suche. Aber nun habe ich wieder ein altes Problem. Ich wähle die DLL aus, aber es werden keine Elemente gefunden, die im Werkzeugkasten positioniert werden können. Im Windows Explorer auf diesem Projekt befindet sich diese Bibliothek auch nicht, nachdem ich darauf verwiesen habe :(

Christian S. - Di 26.07.16 23:05

Was ist denn "die" DLL? Ich habe Dir einen Link zu Google gepostet, das gibt bekanntlich etwas mehr als ein Ergebnis. Woher sollen wir wissen, was Du gerade versuchst zu benutzen? Und schon wieder der Hinweis: Formuliere Deine Fragen so, dass man nicht vor Deinem Rechner sitzen muss, um sie beantworten zu können. :roll:

Delete - Di 26.07.16 23:08

- Nachträglich durch die Entwickler-Ecke gelöscht -

Palladin007 - Di 26.07.16 23:12

Aus dem Grund sollte man NuGet nutzen ;)
Zumindest bei mir hat es bisher noch jedes Projekt komplett funktionsfähig unter den Referenzen unter gebracht und auch brav die Abhängigkeiten nachgezogen.

Danach sollte auch der Designer das mit bekommen, wenn nicht, versuch mal einen Neustart von Visual Studio.

Csharp-programmierer - Mi 27.07.16 09:30

Oh sorry, dass ich vergessen habe die URL von der Downloadseite anzugeben. Hier ist sie

https://officeribbon.codeplex.com/releases/view/113126
Beide Dateien habe ich gedownloaded. Nur die DLL von dem Ordner Binary habe ich genommen, da ich keine andere DLL gefunden habe: System.Windows.Forms.Ribbon35.dll

Und die nimmt er nicht :motz:

Th69 - Mi 27.07.16 10:13

Ich denke mal "35" steht für .NET 3.5, d.h. wenn du eine neuere .NET-Version nutzt, mußt du selber eine passende DLL erzeugen. Zieh dir einfach die Sourcen, ändere das Target-Framework und lass dir die DLL erzeugen.

Palladin007 - Mi 27.07.16 10:28

Scheinbar nimmt der das wirklich nicht auf O.o
Probier mal, den Source direkt als Projekt einzubinden, das ist ja das schöne an OpenSource. Dann sollte der das eigentlich kapieren, nachdem es gebuildet wurde.
Wenn es an der .NET-Version liegt (konnte ich so auf die Schnelle nicht bestätigen), dann kannst Du direkt auch die Version hoch stellen und schauen, ob's dann geht.

Als letzte Alternative:
http://coolthingoftheday.blogspot.com/2009/11/windows-7-ribbon-for-winforms-yes-you.html
Hab ich nicht gelesen, nur gefunden.
So wie ich das verstanden habe, wird dort erklärt, wie man die Ribbons über die WinApi nutzt, aber das würde ich nur als letzte Alternative anschauen. Vielleicht wäre es da sowieso besser, auf WPF umzusteigen, da gibt es sogar von Microsoft selber ein Ribbon-Framework.

Csharp-programmierer - Mi 27.07.16 11:24

Okay, ich werde mir nun selber so etwas basteln. Am besten ginge das ja mit einem userControl. Das habe ich gemacht neues Projekt -> Klassenbibliothek -> userControl hinzufügen
Nun habe ich dieses UserControl in meinen Werkzeugkasten aufgenommen und dieses in einem WindowsForms Projekt hinzugefügt. An sich geht es ja, aber nun würde ich es sehr schön finden, wenn ich die einzelnen Steuerelemente in dem WindowsForms Projekt einzeln mit Events verknüpfen kann. Über die Eigenschaft Modifers habe ich es auch schon versucht :(

Delete - Mi 27.07.16 11:32

- Nachträglich durch die Entwickler-Ecke gelöscht -

Csharp-programmierer - Mi 27.07.16 11:52

Also ich habe die SLN Datei aus SourceCode geöffnet, 4.6 als Zielframework geändert, compilliert. Aber es werden immer noch keine Elemente gefunden, die im Werkzeugkasten positioniert werden können. Aber ich weiß noch nicht ganz, ob man das Ribbon vom rechtlichen her in unserem Programm benutzen kann. Ich bin mehr der Typ, der lieber etwas eigenes macht, anstatt irgendetwas zu benutzen, was ein anderer schonmal gemacht hat.

Mein einziges Problem ist jetzt nur, dass ich in der Klassenbibliothek Benutzersteuerelemente habe, aber auf die einzelnen Controls von diesem UC nicht in einer WinForms Anwendung zugreifen kann.

erfahrener Neuling - Mi 27.07.16 12:02

Hallo Yannic,

Zitat:

aber auf die einzelnen Controls von diesem UC nicht in einer WinForms Anwendung zugreifen kann.

ähnlich wie bei einer Form kannst du eine Instanz dieses UserControls entweder im Quellcode oder über'n Werkzeugkasten erstellen.
Um auf dessen Komponenten zugreifen zu können, müssen diese auch public sein ;)

Delete - Mi 27.07.16 12:08

- Nachträglich durch die Entwickler-Ecke gelöscht -

Palladin007 - Mi 27.07.16 12:22

Eigentlich sollte es reichen, die Referenz zur DLL neu hinzuzufügen
Eventuell muss noch das Projekt neu gebuildet werden.

Zitat:

aber auf die einzelnen Controls von diesem UC nicht in einer WinForms Anwendung zugreifen kann.

Wenn Du das tust, hast Du ganz schnell Abhängigkeiten zwischen deinen Controls, über die Du nicht mehr Herr wirst.
Eigentlich sollte ein Control nicht die Interna eines anderen Controls kennen und die Inhalte deines User Controls zähle ich zu Interna ;)

Csharp-programmierer - Mi 27.07.16 13:27

Zitat:

Das verstehe ich nicht ganz. Angenommen ich habe 5 Buttons auf einem UC. Dann könnte eine Methode dafür sorgen, dass alle Buttons mit dem entsprechenden Event verdrahtet werden. Wenn wir ein Update machen und sich das UserControl ändert, bekomme ich das neue UC und muss dann doch nur noch die neuen Elemente und alles verdrahten, oder? Ich sehe da momentan noch keine Schwierigkeiten :gruebel:

Ralf Jansen - Mi 27.07.16 14:02

Zitat:

Angenommen ich habe 5 Buttons auf einem UC. Dann könnte eine Methode dafür sorgen, dass alle Buttons mit dem entsprechenden Event verdrahtet werden.

Wenn du demm UserControl eine Methode gibst über die jemand von außen dann Events verdrahtet ja. Wenn du das so programmierst das du die Interna des UserControls ändern kannst (z.B. die Buttons durch ein Ribbon ersetzt) und die Form/ContainerControl auf dem dieses UserControl liegt selbst nicht geändert werden muß hast du es richtig gemacht.

Csharp-programmierer - Mi 27.07.16 14:37

Also wir würden es so machen: einer entwickelt das Menü (.dll) und ich verdrahte das alles. Bei einem Update wurde das Menü dann von der Person dementsprechend geändert und ich verdrahte das dann alles neu. So müsste es ja dann eigentlich funktionieren, oder?

Palladin007 - 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 - 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 - Fr 05.08.16 15:19

Fehler

Csharp-programmierer - Fr 05.08.16 15:30

Okay. Ich habe den Fehler gefunden :)

Csharp-programmierer - 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?

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.

Palladin007 - 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 - 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 :)