Diskussion zum Artikel "Benutzerdefinierte grafische Bedienelemente. Teil 3. Formen"
Eine gute und nützliche Arbeit, Dimitri. Es gibt einen Vorschlag für den vierten Teil: "Formular-Assistent" oder "Visueller Formular-Editor", was halten Sie davon?
Respekt, Dimitri. Du hast eine großartige Arbeit geleistet.
Bitte akzeptiere einige Kritikpunkte für die nächste Version der v4-Klassen.
1. Es gibt nicht genug Abstraktion im Basisprojekt. Es hat sich herausgestellt, dass jedes Steuerelement, das Sie haben, als unabhängige Einheit fungiert. Folglich kann man sie z.B. nicht zu einem Array kombinieren.
2. Jede Klasse eines Elements hat nun im Großen und Ganzen einen eigenen Satz von Funktionen. Das ist keine gute Sache. Es sollte einen gemeinsamen Vorfahren geben, dessen Funktionen in den Nachkommen einfach überschrieben werden. Zumal es in den aktuellen Klassen so viele Funktionen mit demselben Namen gibt. Was hält Sie davon ab, einen gemeinsamen Vorfahren zu erstellen?
3. Wenn eine Basisklasse auftaucht, wird es möglich sein, die Ereignisbehandlung innerhalb der Nachkommen zu verstecken, anstatt sie alle außerhalb des Formulars zu platzieren. um eine Kaskade von Ereignissen innerhalb von Objekten zu erzeugen (ähnlich wie CSS im Web).
Aber im Allgemeinen sind alle drei Teile des Artikels preiswürdig, besonders gefallen haben mir die "Nudges" beim Drücken von Schaltflächen und ihre interaktiven Reaktionen auf das Drücken in Abhängigkeit vom Zustand des Elements.
PS.
Und das mehrstufige Menü, das Sie noch fertigstellen, ein separater Artikel darüber ist nicht notwendig, zu dick für so eine kleine Aufgabe, einen neuen Artikel zu schreiben. Lassen Sie es einfach ein Upgrade in der Version v4 sein.
Die CTreeCtrl Baumklasse kann aus dem Artikel https://www.mql5.com/de/articles/272 oder CTreeNode aus dem MT-Kit übernommen werden.
- 2011.03.16
- o_O
- www.mql5.com
Eine gute und nützliche Arbeit, Dimitri. Es gibt einen Vorschlag für den vierten Teil: "Form Wizard" oder "Visual Form Editor", was halten Sie davon?
Persönlich sehe ich das positiv. Aber ist es notwendig? Visual vereinfacht nur die Platzierung von Objekten. Wenn Sie es richtig machen, müssen Sie die Codegenerierung für erstellte Objekte, die Bindung von Variablen oder Klassen an das Objekt binden. Und am wichtigsten: die Ereignisbehandlung.
Aber in diesen nicht-abstrakten Klassen kann man das nicht machen. Sie sind sehr manuell. An vielen Stellen ist es notwendig, neu erstellte Objekte und deren Verarbeitung zu schreiben.
Bei Ereignissen gibt es z.B. keine solche Aufteilung in System und Benutzer - wie Draw (Basissystem) und OnDraw - Ergänzung durch den Benutzer mit einer eigenen Zeichnung.
In anderen Strukturen (zum Beispiel Joomla!) gibt es nicht nur eine eigene Funktion OnDraw. Und es ist in zwei geteilt - BeforDraw und AfterDraw. Das heißt, der Programmierer kann das System-Ereignis EVENT_DRAW behandeln - sowohl vor dem Beginn der Systemzeichnung als auch nach ihrem Ende.
Respekt, Dimitri. Du hast eine großartige Arbeit geleistet.
Bitte akzeptiere einige Kritikpunkte für die nächste Version der v4-Klassen.
1. Es gibt nicht genug Abstraktion im Basisprojekt. Es hat sich herausgestellt, dass jedes Steuerelement, das Sie haben, als unabhängige Einheit agiert. Folglich kann man sie z.B. nicht zu einem Array kombinieren.
2. Jede Klasse eines Elements hat nun im Großen und Ganzen einen eigenen Satz von Funktionen. Das ist keine gute Sache. Es sollte einen gemeinsamen Vorfahren geben, dessen Funktionen in den Nachkommen einfach überschrieben werden. Vor allem, da es so viele Funktionen mit demselben Namen in den aktuellen Klassen gibt. Was hält Sie also davon ab, einen gemeinsamen Vorfahren zu erstellen?
3. Wenn eine Basisklasse auftaucht, wird es möglich sein, die Ereignisbehandlung innerhalb der Nachkommen zu verstecken, anstatt sie alle außerhalb des Formulars zu platzieren. um eine Kaskade von Ereignissen innerhalb von Objekten zu erzeugen (ähnlich wie CSS im Web).
Aber im Allgemeinen sind alle drei Teile des Artikels preiswürdig, besonders gefallen haben mir die "Nudges" beim Drücken von Schaltflächen und ihre interaktiven Reaktionen auf das Drücken in Abhängigkeit vom Zustand des Elements.
PS.
4. Ein mehrstufiges Menü können Sie noch fertigstellen, ein separater Artikel darüber ist nicht notwendig, zu dick für so eine kleine Aufgabe, einen neuen Artikel zu schreiben. Lassen Sie es einfach ein Upgrade in der Version v4 sein.
Die Baumklasse CTreeCtrl kann dem Artikel https://www.mql5.com/de/articles/272 oder CTreeNode entnommen werden, der im MT-Kit angeboten wird.
1- Sie können Steuerelemente eines Typs zu einem Array zusammenstellen. Warum sollten Sie unterschiedliche Steuerelemente in einem Array zusammenfassen wollen?
2. Wenn Sie eine Basisklasse verwenden (eine für alle Steuerelemente), bedeutet dies, dass sie über alle Methoden verfügen muss, die jede der Unterklassen haben kann. Bei unabhängigen Klassen werden in der Dropdown-Liste der Methoden (während der Entwicklung) nur die Methoden angezeigt, die tatsächlich in der Klasse vorhanden sind. Meiner Meinung nach ist das ein sehr wichtiger Punkt. Ich kann mir vorstellen, dass sich jemand hinsetzt und versucht, die Methode SetWidth() für eine vertikale Bildlaufleiste aufzurufen.
Das zweite Argument - alle Klassen sind für Doxygen kommentiert, wenn es eine Basisklasse und Unterklassen gibt, wird die Strukturierung in der Dokumentation nicht so offensichtlich sein.
Ich versuche, fertige Lösungen so zu erstellen, dass sie mit "geschlossenen Augen" verwendet werden können. Um den Prozess der Erstellung eines neuen Steuerelements zu beschleunigen, können Sie eine Vorlage mit allen obligatorischen Methoden verwenden.
3. ich verstehe nicht ganz. Wenn ein Steuerelement ein anderes Steuerelement enthält, wird seine Ereignisbehandlung ausgeblendet. In jedem Fall müssen Sie Event() für jedes Steuerelement aufrufen.
4. Ich weiß nicht, vielleicht... Ich habe meine eigene Klasse, die speziell für die Erstellung von Menüs entwickelt wurde. Es ist nicht notwendig, AddNode() aufzurufen, AddItem() wird aufgerufen, und die Ebene wird durch die Anzahl der Leerzeichen bestimmt, mit denen der Name des Elements beginnt. Der Prozess der Erstellung eines Baumes ist sehr übersichtlich. Bisher funktioniert es mit der Anzeige in der Kommentar- und Tastensteuerung. Im Allgemeinen können Sie mehrere Baummenüs erstellen: 1) wie ein normales Hauptmenü mit Dropdown-Registerkarten, 2) mit Anzeige der Elemente einer Registerkarte und dem Pfad nach oben, 3) mit Baumanzeige (wie windos explorer).
1. ich persönlich sehe das positiv. Aber ist es notwendig? Die Visualisierung vereinfacht nur die Platzierung von Objekten. Wenn man es richtig macht, muss man die Codegenerierung für erstellte Objekte, die Bindung von Variablen oder Klassen an das Objekt binden. Und vor allem die Verarbeitung von Ereignissen.
2. Aber in diesen nicht-abstrakten Klassen kann das nicht gemacht werden. Sie sind sehr manuell. Es ist notwendig, an vielen Stellen neu erstellte Objekte und deren Verarbeitung zu schreiben.
Bei Ereignissen gibt es zum Beispiel keine solche Aufteilung in System und Benutzer - wie Draw (Basissystem) und OnDraw - ein Zusatz vom Benutzer mit eigener Zeichnung.
In anderen Strukturen (zum Beispiel Joomla!) gibt es nicht nur eine eigene Funktion OnDraw. Und es ist in zwei geteilt - BeforDraw und AfterDraw. Das heißt, der Programmierer kann das Systemereignis EVENT_DRAW behandeln - sowohl vor dem Beginn des Systemzeichnens als auch nach dessen Ende.
1. Es wird möglich sein, automatisch den Code für die Behandlung von Ereignissen von Steuerelementen zu generieren und Ereignisfunktionen für alle Steuerelemente zu erhalten, wie HScrollBar1_OnChange()....
2. Es gibt noch keine Ereignisse, zum Beispiel, wenn Werte programmatisch gesetzt werden, werden Ereignisse nur erzeugt, wenn Werte vom Benutzer eingegeben werden. Dies ist ein ausreichendes Minimum, nichts Zusätzliches. Andernfalls wird jemand, der selbst programmieren lernt, mit Ereignissen überflutet.
Eine gute und nützliche Arbeit, Dimitri. Es gibt eine Anregung für den vierten Teil: "Form Wizard" oder "Visual Form Editor". Wie sehen Sie das?
... Es gibt einen Vorschlag für Teil 4: "Form Wizard" oder "Visual Form Editor", was halten Sie davon?
1. Einzelne Kontrolltypen können in einem Array zusammengefasst werden. Warum sollen verschiedene Arten von Steuerelementen in einem Array zusammengefasst werden?
Um alles in eine Schleife zu bringen und bestimmte Typen in der Ereignisverwaltung loszuwerden.
2. Wenn Sie eine Basisklasse verwenden (eine für alle Steuerelemente), bedeutet das, dass sie alle Methoden haben muss, die jede der Unterklassen haben kann. Bei unabhängigen Klassen werden in der Dropdown-Liste der Methoden (während der Entwicklung) nur die Methoden angezeigt, die tatsächlich in der Klasse vorhanden sind. Meiner Meinung nach ist das ein sehr wichtiger Punkt. Ich kann mir vorstellen, dass jemand sitzt und versucht, die Methode SetWidth() für einen vertikalen Rollbalken aufzurufen.
Alle Funktionen in der Basisklasse sind leere Stopper mit minimaler allgemeiner Funktionalität. Selbst wenn jemand unwissentlich eine nicht verwandte Funktion für ein Element aufruft, wird absolut nichts Schlimmes passieren. das ist die Stärke von OOP. Polymorphismus.
Das zweite Argument - alle Klassen sind für Doxygen kommentiert, wenn es eine Basisklasse und Unterklassen gibt, wird es nicht so eine offensichtliche Strukturierung in der Dokumentation geben.
Es wird sie geben, nur wird sie anders sein... :)
- 2010.03.25
- MetaQuotes Software Corp.
- www.mql5.com
1. alles in eine Schleife zu packen und bestimmte Typen in der Ereignisverwaltung loszuwerden.
2. der Punkt ist, dass die Basisklasse - es hat keine Implementierung von Funktionen der spezifischen Aktionen. alle Funktionen in der Basisklasse sind leere Stopper mit minimalen allgemeinen Funktionalität. Selbst wenn jemand unwissentlich eine nicht verwandte Funktion für ein Element aufruft, wird absolut nichts Schlimmes passieren. das ist die Stärke von OOP. Polymorphismus hingegen.
3. es wird. nur wird es anders sein.... :)
1. ist das alles? Nur um Punkt 2 durcheinander zu bringen - Methoden-Dump?
Alternativen:
1) Die Notwendigkeit, manuell einen Event()-Aufruf für jede Klasse hinzuzufügen (was darin besteht, mit der Maus eine Zeile zu kopieren und ein paar Buchstaben links vom Punkt zu ändern) und gleichzeitig in der Liste der Methoden jeder Klasse haben wir nur Arbeitsmethoden, die dieser Klasse entsprechen, den Punkt angeklickt, die Liste erscheint und alles ist klar.
2) Automatische Verarbeitung von Event() aller Klassen, während eine Funktion noch von OnChartEvent() aufgerufen werden muss, und auf der anderen Seite: ein Dump der Methoden in der Liste. Außerdem müssten Sie Zeiger im Deinit zerstören.
Schauen Sie etwas tiefer und weiter, warum alle Event() in einer Schleife abgearbeitet werden sollten, jedes Steuerelement sollte seine eigenen Aktionen für sein Event() haben, Steuerelemente sind nicht nur dazu da, um einen Wert einzugeben und nicht nur, um alles auf dem Bildschirm zu bewegen und flackern zu lassen, sondern auch (zum größten Teil) um die eingegebenen Werte im Programm zu verwenden.
3. Sie werden etwa die Hälfte der Methoden eines Steuerelements an einer Stelle in der Dokumentation lesen müssen und die andere Hälfte an einer anderen.
1. das war's? Um sich mit Punkt 2 - dem Dumping von Methoden - zu beschäftigen?
Alternativen:
1) Die Notwendigkeit, manuell einen Event()-Aufruf für jede Klasse hinzuzufügen (was darin besteht, mit der Maus eine Zeile zu kopieren und ein paar Buchstaben links vom Punkt zu ändern) und gleichzeitig in der Liste der Methoden jeder Klasse haben wir nur Arbeitsmethoden, die dieser Klasse entsprechen, klickte auf den Punkt, die Liste fiel heraus und alles ist klar.
2) Automatische Verarbeitung von Event() aller Klassen, während eine Funktion noch von OnChartEvent() aufgerufen werden muss, und auf der anderen Seite: ein Dump der Methoden in der Liste. Außerdem müssen wir Zeiger im Deinit zerstören.
Schauen Sie etwas tiefer und weiter, warum alle Event() in einer Schleife abgearbeitet werden sollten, jedes Steuerelement sollte seine eigenen Aktionen für sein Event() haben, Steuerelemente sind nicht nur dazu da, um einen Wert einzugeben und nicht nur, um alles auf dem Bildschirm zu bewegen und flackern zu lassen, sondern auch (zum größten Teil), um die eingegebenen Werte im Programm zu verwenden.
3. Sie werden etwa die Hälfte der Methoden eines Steuerelements an einer Stelle in der Dokumentation lesen müssen und die andere Hälfte an einer anderen.
Sie haben alles richtig gemacht.
Angesichts der Möglichkeiten von ME ist das ganz praktisch, japanischer Minimalismus im Zeitalter des totalen Kitsches, alles ist da, nichts überflüssig.
Wer Objekte durchschleifen will, kann eine Postfix-Shell implementieren, in die er schreiben kann, was er will.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Neuer Artikel Benutzerdefinierte grafische Bedienelemente. Teil 3. Formen :
Dies ist der letzte der drei Beiträge, die sich grafischen Bedienelementen widmen. Er behandelt die Erstellung der Hauptkomponente der grafischen Oberfläche – der Form – und ihre Verwendung in Kombination mit anderen Bedienelementen. Zusätzlich zu den Formklassen wurden die Klassen CFrame, CButton und CLabel der Bibliothek von Bedienelementen hinzugefügt.
Autor: Dmitry Fedoseev