Hallo,

Du musst den Namespace angeben.
Ganz oben in Deinem Quellcode musst Du folgendes angeben:



Vererbungshierarchie
System.Object
System.Windows.Forms.MessageBox



PS: Evt. musst Du auch einen entsprechenden Verweis angeben
Und zwar Doppelklick auf MyProject, dann auf Verweise, und dann unten den System.Windows.Forms einhacken

Wenn du dir diese Frage stellst solltest du das grundsätzliche Design deiner Klassenbibliothek mal überdenken. In der Regel hat die Klasse nur die Aufgabe Informationen über Schnittstellen (Events) nach außen abzugeben, nicht aber die Aufgabe die Anzeige zu steuern. Ich würde dir empfehlen ein Buch über die Objekt-Orientierung / objektorientierte Programmierung zu lesen.

Gruß,

f0x

Hallo f0x,

Sinn von Biblotheken (dll´s) ist, Funktionalitäten und Mechanismen, nicht mehrfach, innerhalb einer Anwendung implementieren zu müssen.
Dies würde unnötige Redundanzen im Code erzeugen.
Außerdem erlauben sie, bei sehr großen Anwenugen eine belibig feine Unterteilung, welche wiederum das Auffinden von Fehlern erleichert
und die Auslieferung von kleinen Bugfix Paketen ermöglicht.
Ob nun GUI oder reine Anwendungslogik in einer dll untergebracht ist, hat m.E. nichts mit Objektorientierung zu tun,
sondern es hängt schlicht mit den Anforderungen und Bedürfnissen zusammen.
Es liegt also einzig im Ermessen des Entwicklers, bzw. eines Teams, wie die Programmteile "untergebracht" werden.

Korrigier mich ruhig, wenn Du´s anders siehst.

Gruß!

PS: Quelle Wikipedia

Sowohl EXE- als auch DLL-Dateien können Programmcode (Maschinencode), Daten und Ressourcen in irgendeiner Kombination enthalten.
Der Zweck von DLL-Dateien ist, den von einer Anwendung auf der Festplatte und im Hauptspeicher benötigten Speicherplatz zu reduzieren. Jeglicher Programmcode, der von mehr als einer Anwendung benötigt werden könnte, wird deshalb in einer einzelnen Datei auf der Festplatte gespeichert und nur einmal in den Hauptspeicher geladen, wenn mehrere Programme dieselbe Programmbibliothek benötigen.

Toll, aus Wikipedia... aus der Erfahrung weiß man´s besser.

Warum sollte es sonst ControlLibraries geben?

Hallo Peter,

grundsätzlich sehe ich das nicht anders als du. Es hat jedoch einen Grund warum der Windows.Forms-Namespace nicht per default importiert wird bei diesen Projekttypen. Was das mit Redudanz oder einer Feingliederung zu tun haben soll kann ich nicht nachvollziehen, da mußt du mich aufklären. Es geht auch nicht darum ob eine GUI implementiert werden darf.. mal abgesehen davon daß dann im Normalfall sowieso der Forms Namespace importiert ist und sich die Frage nach der Verfügbarkeit der Klassenmethode MessageBox erübrigt. Bei bei Programmierung von Klassen geht es um Abstraktion. Häufig ist der Entwickler einer Klasse nicht der, der sie dann importiert, bzw. weiß der Entwickler der Klasse nicht wie selbige eingesetzt werden wird. Von daher strebt man bei der Entwicklung einen möglichst hohen Abstraktionsgrad an. Und dazu gehört im Normalfall daß eine Klasse nicht die Bildschirmausgabe von Fehlermeldungen steuert. In diesem Kontext sind m.W. zwei Arten von Fehlern denkbar. Die eine Art ist die, die unter keinen Umständen auftreten dürfen, diese werden mittels Try-Catch abgesichert und liefern einen Rückgabewert an den Aufrufer der darauf hinweist daß bei der Verarbeitung etwas schief gegangen ist. Die zweite Art sind jene Fehler die prinzipbedingt anfallen und wo sich nur die Frage stellt wie der Anwender der Klasse darauf reagieren möchte. Je nachdem wie stark dieser Grad der Mitbestimmung ausfallen soll werden entweder Exceptions an die Aufrufende Instanz geworfen oder Events ausgelöst. Ob ein Anwender der Klase auf diese Events reagieren will oder nicht, darf den Entwickler der Klasse gar nicht interessieren.

Ganz praktisch ausgedrückt.. man macht das einfach nicht daß eine Klassenbibliothek Fehlermeldungen direkt ausgibt. Um nur ein einziges Beispiel zu nennen... Anwendungsentwickler die auf ein homogenes Aussehen in der Anwendung Wert legen und daher zentrale Fehlerbehandlungsroutinen einrichten um die Fehlerausgabe zu steuern, werden sich bestimmt nicht darüber freuen wenn eine verwendete Klassenbibliothek MessageBoxen auswirft, was sich schon rein optisch von den anderen Fehlermeldungen im Programm abhebt.

Natürlich kann man das streng und weniger streng sehen, zumal wenn man einen Hobby-Hintergrund bei der Programmierung hat und man sowieso der einzige Anwender der selbst erstellten Klasse ist, aber... meiner Meinung nach sollte man sich trotzdem möglichst schon von Beginn an die gleichen Maßstäbe setzen, die dafür allgemein akzeptiert sind. Daher der Verweis auf ein morderne Buch zur Objektorientierung. Bedenke immer eines... es ist sehr viel leichter etwas gleich "richtig" zu lernen als lange zu schludern und irgendwann umdenken zu müssen.

Gruß,

f0x

Hallo,

ja Deine Ausführung ist wirklich sehr plausibel.
Von der Warte her gesehen gebe ich Dir vollkommen Recht.

Dennoch weiß ich dass gerade in Teams, wo unterschiedliches Niveau und, ich nennen das mal
unterschiedliche Programmierkultur herrscht, ein hoher Abstraktionsgrad, unterm Strich wenig Wirkung zeigt.
Wenn an vielen Stellen nicht im Geringsten darauf geachtet wird, weder auf Abstraktion (geschweige denn einen hohen Grad)
noch auf homogenes Erscheinungsbild.
In Teams in denen jeder sein eigenes Süppchen kocht, bei denen nicht der, der die meiste Erfahrung hat Leader ist,
sondern einer der aufgrund seiner Position "das Sagen" hat.

Wobei, so wie bei uns auch, mag es Programme geben, bei denen die einzelnen Entwickler
Bereich für Bereich, von A bis Z im Alleingang entwickeln und diesen Bereich dann auch betreuen.
Es gibt einige allgemeine Klassen, dort wird tatsächlich wenig mit Fehlermeldungen gearbeitet,
eher mit Return-Werten.

Aber Dein Ansatz ist auf jeden Fall sehr gut!

Gruß!