Diskussion zum Artikel "Grafische Interfaces II: Die Trennlinien und Context-Menüelemente (Kapitel 2)"

Neuer Kommentar
 

Neuer Artikel Grafische Interfaces II: Die Trennlinien und Context-Menüelemente (Kapitel 2) :

In dem vorherigen Kapitel haben wir eine Klasse für die Erzeugung eines Menüpunktes geschrieben. Diese wird sowohl als unabhängiges Control und als ein Teil eines Kontextmenüs und eines Hauptmenüs verwendet. In diesem Artikel erzeugen wir das Trendlinien-Element. Es kann nicht nur als unabhängiges Interface-Element verwendet werden, sondern auch als ein Teil von vielen anderen Elementen. Anschließend haben wir alles, was für die Entwicklung der Kontextmenü Klasse benötigt wird. Diese Klasse werden wir in diesem Artikel im Detail besprechen. Zudem werden wir alle notwendigen Ergänzungen dieser Klasse hinzufügen, die für das Abspeichern von Pointern aller Elemente des grafischen Interfaces dieser Anwendung benötigt werden.

Entwicklung einer Klasse für die Erzeugung einer Trennlinie

In Kontextmenüs, sehen wir neben verschiedenen Typen von Menüpunkten, auch ein weiteres Interface-Element, eine Trennlinie. Dieses Element kann nicht nur in Kontextmenüs verwendet werden. Zum Beispiel besitzt die Statusbar des MetaTrader Trading-Terminals und des MetaEditor Code-Editors ebenfalls vertikale Trennlinien. Dieses ist der Grund, warum wir hierfür eine eigenständige Klasse entwickeln. Somit kann Sie in jedem anderen Control oder auch als separates Element eines grafischen Interfaces verwendet werden.

Um einen Eindruck des Umfangs dieses Vorhabens gewinnen zu können: Eine Trennlinie muss aus mindestens zwei Teilen bestehen. Falls eine Linie heller als ihr Hintergrund ist und eine andere Linie dunkler, dann erzeugt dieses den Eindruck einer Nut auf der Oberfläche. Es gibt zwei Wege, wie eine Trennlinie erzeugt werden kann: (1) Über zwei einfache Objekte des Typs CRectLabel, welche bereits in der Objects.mqh Datei existieren, oder (2) über die Erzeugung des Objektes vom Typ OBJ_BITMAP_LABEL welches dann als Grundlage für weitere Zeichnungen dient. Lassen Sie uns die zweite Option verwenden. Die Standardbibliothek schlägt die CCanvas Klasse für das Zeichnen vor. Diese Klasse besitzt bereits alle notwendigen Methoden für das Zeichnen von einfachen geometrischen Objekten, was uns die Implementation unseres Vorhabens erheblich erleichtern wird. 

Die CCanvas Klasse muss so eingefügt werden, dass sie auf die gleiche Art und Weise verwendet werden kann, wie auch andere primitive Objekte, welche bereits in der Objects.mqh Datei existieren. Dieses können wir ganz einfach dadurch erreichen, indem wir die CCanvas Klasse von der CChartObjectBmpLabel Klasse ableiten. Wir müssen lediglich kleinere Änderungen an den Programmcode der CCanvas Klasse vornehmen, damit es später beim Kompilieren des Programms nicht zu Fehlermeldungen kommt. Dies liegt daran, dass es in beiden Klassen, der CCanvas Klasse und der CChartObject Klasse, die als Basis für unsere CChartObjectBmpLabel Klasse dient, ein Feld (variable) mit dem Namen m_chart_id gibt. Aus diesem Grunde wird der Compiler später eine Warnung ausgeben, dass dieser Variablen-Name bereits existiert:

Abbildung 1. Die Warnung des Compilers, dass es eine Variable mit gleichem Namen schon gibt.

Autor: Anatoli Kazharski

 
Gibt es einen Mechanismus zum Binden/Delegieren von Aktionen/Befehlen an verschiedene Steuerelemente? Zum Beispiel an eine Schaltfläche in der Symbolleiste und einen Kontextmenüeintrag? Das "Command"-Muster wäre dafür geeignet. Gleichzeitig ist es möglich, einen Undo/Redo-Mechanismus zu implementieren, indem man in der Historie der ausgeführten Befehle die Anfangswerte des Empfängers speichert.

Es ist auch gut, das Konzept eines Modells einzuführen, das von diesem oder jenem Steuerelement abgehört wird (Musterbeobachter). Dadurch können alle Steuerelemente in der Schnittstelle transparent auf Änderungen im Modell reagieren.

Solange das Diagramm-Modell nicht vom Benutzer initialisiert wurde, haben beispielsweise alle Steuerelemente, die sich auf die Diagrammverwaltung beziehen, eine deaktivierte Ansicht. Dadurch entfällt die Notwendigkeit eines direkten Zugriffs auf die Steuerelemente und die Logik, die für ihr Verhalten in bestimmten Fällen verantwortlich ist.
 
Igor Volodin:
Gibt es einen Mechanismus zum Binden/Delegieren von Aktionen/Befehlen an verschiedene Steuerelemente? Zum Beispiel an eine Schaltfläche in der Symbolleiste und einen Kontextmenüeintrag? Das "Command"-Muster wäre dafür geeignet. Gleichzeitig ist es möglich, einen Undo/Redo-Mechanismus zu implementieren, indem man in der Historie der ausgeführten Befehle die Anfangswerte des Empfängers speichert.

Es ist auch gut, das Konzept eines Modells einzuführen, das von diesem oder jenem Steuerelement abgehört wird (Musterbeobachter). Dadurch können alle Steuerelemente in der Schnittstelle transparent auf Änderungen im Modell reagieren.

Solange das Diagramm-Modell nicht vom Benutzer initialisiert wurde, haben beispielsweise alle Steuerelemente, die mit der Diagrammverwaltung zusammenhängen, eine deaktivierte Ansicht. Damit entfällt in bestimmten Fällen die Notwendigkeit eines direkten Zugriffs auf die Steuerelemente und die für ihr Verhalten verantwortliche Logik.

In der aktuellen Version der Bibliothek wird in einigen Fällen der Austausch von Befehlen zwischen den Elementen durch benutzerdefinierte Ereignisse implementiert. Der nächste Artikel wird mehr darüber berichten.

Was zusätzliche Mechanismen betrifft, so ist alles verhandelbar. Nach der Veröffentlichung der gesamten Serie können Sie alle Elemente des Schemas durchgehen und eine Liste erstellen, was geändert oder hinzugefügt werden sollte, wenn es Argumente gibt, warum es besser/zuverlässiger/bequemer wäre, usw.

Vielleicht habe ich die Frage missverstanden. Dann müssen Sie klären, was genau Sie brauchen und wie es aussehen soll.

 
Warum ein Array von Variablen? 
color             m_area_color_array[];
Und im CContextMenu()-Konstruktor müssen Sie die Variable m_item_Ysize standardmäßig auf eine Größe größer als Null setzen.
Neuer Kommentar