Diskussion zum Artikel "MQL als Darstellungsmittel für graphische Schnittstellen von MQL-Programmen. Teil 2"
All dies funktioniert also nur mit einer erweiterten Version der Standardbibliothek?
Ich werde den Artikel nicht lange kritisieren, denn es ist bereits klar, dass der Autor nicht an den Leser denkt. Er spricht zu sich selbst und wird von denjenigen verstanden werden, die mit der Standardbibliothek - ihren Klassen, Methoden und Variablen - bestens vertraut sind. Der Autor "galoppiert" durch die ihm bekannten Codes und ändert etwas....
Und wer diese Bibliothek perfekt kennt, wird kaum noch Ergänzungen brauchen.
Und jemand, der mit dieser Bibliothek bestens vertraut ist, wird wahrscheinlich keine Ergänzungen benötigen.
Wenn Sie den Schluss des Artikels aufmerksam lesen, können Sie die (umstrittenen) Schlussfolgerungen des Autors nachvollziehen:
//------------------------------------------------------------------------------------------------------------------------
1. Der Autor behauptet, "die Durchführbarkeit des Konzepts zur Beschreibung des Layouts der grafischen Schnittstelle von MQL-Programmen in der MQL-Sprache selbst" (c) geprüft zu haben.
- Aufgrund der Besonderheiten der Materialpräsentation kann ich nichts für oder gegen diese Schlussfolgerung sagen. Es ist nicht offensichtlich.
//------------------------------------------------------------------------------------------------------------------------
2. "Die Verwendung der dynamischen Generierung von Elementen mit zentraler Speicherung im Cache ermöglicht es, die Erstellung und Verwaltung der Komponentenhierarchie zu vereinfachen. Die meisten Aufgaben im Zusammenhang mit der Schnittstellengestaltung, wie einheitliche Stiländerungen, Ereignisbehandlung, fliegende Bearbeitung des Layouts und Speicherung in einem für die spätere Verwendung geeigneten Format, können auf der Grundlage des Cache implementiert werden." (c)
- Es ist unklar, auf welcher theoretischen Grundlage diese Schlussfolgerung gezogen wurde, da es keine Beschreibung der Technologie gibt und der Leser weder zustimmen noch verneinen kann. Der Leser sollte in die Technologie eingeführt werden und dann wird er dem Nachweis der Realisierbarkeit zustimmen.
//------------------------------------------------------------------------------------------------------------------------
3. "Wenn man diese Eigenschaften zusammennimmt, stellt sich heraus, dass für einen einfachen visuellen Formular-Editor so ziemlich alles zur Verfügung steht. Er könnte nur die wichtigsten Eigenschaften unterstützen, die vielen "Steuerelementen" gemeinsam sind, würde aber dennoch die Bildung von Schnittstellen-Rohlingen ermöglichen."(c)
- Auch hier gilt - ohne eine verallgemeinerte Beschreibung der technologischen Feinheiten kann der Leser, der das System zur Erstellung visueller Editoren aus Graphbibliotheken nicht genau kennt, dem Autor weder zustimmen noch widersprechen. Es ist nicht offensichtlich.
//------------------------------------------------------------------------------------------------------------------------
4. "Wir sehen jedoch, dass schon die erste Phase der Evaluierung des neuen Konzepts viel Aufwand erforderte. Einen vollwertigen Editor in der Praxis zu implementieren, ist daher eine ziemliche Herausforderung. Und das ist eine andere Geschichte." (c)
- Meiner Meinung nach ist dies die objektivste Schlussfolgerung. Das heißt - "die Implementierung eines vollwertigen Editors ist eine andere Geschichte". Ich würde dieser Schlussfolgerung zustimmen. Man kann es nicht einfach "überstürzen" (ich selbst versuche es schon seit mehreren Jahren).
//------------------------------------------------------------------------------------------------------------------------
Meine Schlussfolgerung: In der Schlussfolgerung des Artikels (nämlich in der letzten Schlussfolgerung) ist der Autor der Realität am nächsten. Aber der Artikel richtet sich an Leser, die im Laufe der Entwicklung des Themas zu den gleichen Schlussfolgerungen kommen sollten, und zu diesem Zweck ist es notwendig, die Technologie schrittweise zu enthüllen. Der größte Nachteil der beiden Artikel besteht darin, dass die Technologie nicht offengelegt wird. Ihr Inhalt ist eine Diskussion über die Umsetzung der nicht offensichtlichen Lösungen des Autors ohne jegliche Vorrede zu ihnen. Ich hoffe, der Autor wird dies berücksichtigen.
- www.mql5.com
Wenn Sie den Schluss des Artikels aufmerksam lesen, können Sie die (kontroversen) Schlussfolgerungen des Autors nachvollziehen:
//------------------------------------------------------------------------------------------------------------------------
1. der Autor behauptet, "die Durchführbarkeit des Konzepts zur Beschreibung des Layouts der grafischen Schnittstelle von MQL-Programmen in der MQL-Sprache selbst" (c) geprüft zu haben.
- Aufgrund der Besonderheiten der Materialpräsentation kann ich nichts für oder gegen diese Schlussfolgerung sagen. Sie ist nicht offensichtlich.
//------------------------------------------------------------------------------------------------------------------------
2. "Die Verwendung der dynamischen Elementgenerierung mit zentraler Speicherung in einem Cache erleichtert die Erstellung und Verwaltung einer Hierarchie von Komponenten. Die meisten Aufgaben im Zusammenhang mit der Gestaltung der Benutzeroberfläche können auf der Grundlage des Cache durchgeführt werden, wie z. B. einheitliche Stiländerungen, Ereignisbehandlung, Bearbeitung des Layouts während des Betriebs und Speicherung in einem für die spätere Verwendung geeigneten Format." (c)
- Es ist nicht bekannt, auf welcher theoretischen Grundlage diese Schlußfolgerung gezogen wurde, da es keine Beschreibung der Technologie gibt und der Leser weder zustimmen noch verneinen kann. Der Leser sollte in die Technologie eingeführt werden und dann wird er dem Nachweis der Realisierbarkeit zustimmen.
//------------------------------------------------------------------------------------------------------------------------
3. "Nimmt man diese Eigenschaften zusammen, so stellt sich heraus, dass für einen einfachen visuellen Formular-Editor so ziemlich alles vorhanden ist. Er könnte nur die wichtigsten Eigenschaften unterstützen, die vielen "Steuerelementen" gemeinsam sind, und dennoch die Möglichkeit bieten, leere Schnittstellen zu gestalten."(c)
- Auch hier gilt - ohne eine verallgemeinerte Beschreibung der technologischen Feinheiten kann der Leser, der das System der Erstellung visueller Editoren aus Graphbibliotheken nicht kennt, dem Autor weder zustimmen noch widersprechen. Es ist nicht offensichtlich.
//------------------------------------------------------------------------------------------------------------------------
4. "Wir sehen jedoch, dass schon die erste Phase der Evaluierung des neuen Konzepts viel Aufwand erforderte. Einen vollwertigen Editor in der Praxis zu implementieren, ist also eine ziemliche Herausforderung. Und das ist eine andere Geschichte." (c)
- Meiner Meinung nach ist dies die objektivste Schlussfolgerung. Das heißt, "die Implementierung eines vollwertigen Editors ist eine andere Geschichte". Ich würde dieser Schlussfolgerung zustimmen. Man kann es nicht einfach "dreist" machen (ich habe es selbst mehrere Jahre lang versucht).
//------------------------------------------------------------------------------------------------------------------------
Mein Fazit: In der Schlussfolgerung des Artikels (nämlich in der letzten Schlussfolgerung) ist der Autor der Realität am nächsten. Aber der Artikel richtet sich an Leser, die im Laufe der Entwicklung des Themas zu den gleichen Schlussfolgerungen kommen sollten, und zu diesem Zweck ist es notwendig, die Technologie schrittweise zu enthüllen. Der größte Nachteil der beiden Artikel besteht darin, dass die Technologie nicht offengelegt wird. Ihr Inhalt ist eine Diskussion über die Umsetzung der nicht offensichtlichen Lösungen des Autors ohne jegliche Vorrede zu ihnen. Ich hoffe, der Autor wird dies berücksichtigen.
Ich werde mich der Stimme enthalten, weil es sich nicht lohnt.
Ich habe den Inhalt des Artikels gründlich analysiert und festgestellt, dass es zwar "Teilchen" der von mir gesuchten Technologie gibt, diese aber willkürlich über das gesamte Material verstreut sind. Das heißt, der Autor hat die Theorie nicht von der Implementierung getrennt und alles durcheinandergeworfen, wobei er es mit einer Fülle von Codebeispielen trennte. Ich beschloss, die Grundlagen seines Konzepts an einem Ort zu sammeln, um mir ein vollständiges Bild davon zu machen.
Kopien der Artikelfragmente, in denen die Technologie erklärt wird (die Reihenfolge bleibt erhalten, Codebeispiele werden weggelassen):
//--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1. Die allgemeine Struktur der Bibliothek der Standardelemente, unter Berücksichtigung angepasster Versionen mit Unterstützung für "rubberstamping" und Container von Drittanbietern, ist im Klassendiagramm dargestellt. (mein Zusatz: das Diagramm ist vorhanden).
2. Elementgenerierung und Caching
Bislang wurden Elemente als automatische Instanzen innerhalb eines Fensterobjekts konstruiert. Sie sind im Wesentlichen "Rohlinge", die dann durch Methoden wie Create initialisiert werden. Das GUI-Element-Layout-System kann diese Elemente selbst erzeugen, anstatt sie aus einem Fenster zu holen. Zu diesem Zweck ist es ausreichend, eine Art von Speicher zu haben. Nennen wir ihn LayoutCache. Im Grunde handelt es sich um ein Array von Zeigern der Basisklasse (die für alle Elemente gleich sind), in dem sie mit der Speichermethode abgelegt werden können. Die Schnittstelle implementiert auch (wenn auf dieser abstrakten Ebene möglich) oder deklariert (für spätere Überschreibungen) Methoden zur Suche nach Elementen nach Nummer, Name, Referenz oder der Tatsache der "Eltern"-Beziehung (Rückkopplung von verschachtelten Elementen zum Container).
Fügen wir einen Cache als statisches Mitglied der Klasse LayoutBase hinzu. Jedes Fenster muss für sich selbst eine Cache-Instanz erzeugen und diese mit setCache am Anfang einer Methode wie CreateLayout als Arbeits-Cache festlegen. Da MQL-Programme single-threaded sind, haben wir eine Garantie, dass Fenster (falls mehrere benötigt werden) nicht parallel gebildet werden und um den Cache-Zeiger konkurrieren. Wir löschen den Zeiger automatisch im Destruktor von LayoutBase, wenn der Stack zu Ende ist - das bedeutet, dass wir den letzten Außencontainer in der Layoutbeschreibung belassen haben und es nicht nötig ist, etwas anderes zu speichern. Das Löschen der Referenz bedeutet nicht, dass wir den Cache leeren. Es stellt nur sicher, dass das potenzielle nächste Layout nicht versehentlich "Controller" aus einem anderen Fenster hinzufügt. Um den Cache zu füllen, fügen wir eine neue Art von init-Methode zu LayoutBase hinzu - diesmal ohne einen Zeiger oder eine Referenz auf ein "fremdes" GUI-Element in den Parametern. Dank des Templates haben wir die Möglichkeit, ein neues T zu schreiben und Objekte während des Layout-Prozesses zu erzeugen (standardmäßig 1 Objekt auf einmal, aber optional können wir mehrere haben).
Eine konkrete Cache-Implementierung wurde für die Elemente der Standardbibliothek geschrieben - StdLayoutCache (hier mit Abkürzungen angegeben, der vollständige Code befindet sich im Anhang).
Beachten Sie, dass die get-Methode ein "Steuerelement" entweder anhand der Sequenznummer (wenn der Eingabeparameter positiv ist) oder anhand des Bezeichners (er wird mit einem Minuszeichen übergeben) sucht. Mit Bezeichner ist hier eine eindeutige Nummer gemeint, die von der Bibliothek der Standardkomponenten für die Ereignisabwicklung vergeben wird. Bei Ereignissen wird sie im Parameter lparam übergeben.
3. styliser
Da der Cache ein Objekt ist, das Elemente zentral verarbeitet, ist es praktisch, ihn neben dem Styling auch für viele andere Aufgaben zu verwenden. Insbesondere können die Regeln eines einzigen Stils (Farbe, Schriftart, Einrückung) auf einheitliche Weise auf Elemente angewendet werden. Es reicht aus, diesen Stil an einer Stelle zu konfigurieren, anstatt dieselben Eigenschaften für jedes "Steuerelement" einzeln zu schreiben. Darüber hinaus kann der Cache die Aufgabe übernehmen, Nachrichten für zwischengespeicherte Elemente zu verarbeiten. Potenziell können wir dynamisch alle Elemente konstruieren, zwischenspeichern und mit ihnen interaktiv umgehen. Dann brauchen wir überhaupt keine "expliziten" Elemente im Fenster zu deklarieren. Etwas später werden wir sehen, wie sich dynamisch erzeugte Elemente im Vergleich zu automatischen Elementen bewähren.
Um zentralisierte Stile zu unterstützen, verfügt die Klasse StdLayoutCache über eine Stall-Methode: Die apply-Methode wird für jedes "Steuerelement" zweimal aufgerufen: in der Initialisierungsphase (STYLE_PHASE_BEFORE_INIT) und in der Registrierungsphase im Container (STYLE_PHASE_AFTER_INIT). Daher fügen die LayoutBase::init-Methoden einen Aufruf für die erste Phase hinzu: und der Destruktor fügt ähnliche Zeichenfolgen hinzu, jedoch mit STYLE_PHASE_AFTER_INIT für die zweite Phase.
Zwei Phasen sind erforderlich, weil die Zwecke der Gestaltung unterschiedlich sind. Einige Elemente benötigen manchmal individuelle Eigenschaften, die eine höhere Priorität haben als die allgemeinen, die im Stylizer festgelegt sind. In der Initialisierungsphase ist das "Steuerelement" noch leer - ohne die im Layout vorgenommenen Einstellungen. In der Registrierungsphase sind alle Eigenschaften bereits eingestellt, und Sie können zusätzlich den Stil auf der Grundlage dieser Eigenschaften ändern. Das offensichtlichste Beispiel ist das folgende. Es ist wünschenswert, alle Eingabefelder mit dem Kennzeichen "schreibgeschützt" in grau darzustellen. Aber die Eigenschaft "schreibgeschützt" wird dem "Steuerelement" während des Layoutprozesses, nach der Initialisierung, zugewiesen, so dass die erste Stufe nicht geeignet ist und die zweite Stufe erforderlich ist. Andererseits werden in der Regel nicht alle Eingabefelder dieses Kennzeichen haben, und in allen anderen Fällen ist es notwendig, die Standardfarbe einzustellen, bevor die Layoutsprache eine selektive Anpassung vornimmt.
Eine ähnliche Technik kann übrigens auch für die zentralisierte Lokalisierung der Oberfläche von MQL-Programmen in verschiedene Landessprachen verwendet werden.
4. Ereignisverarbeitung
Die zweite Funktion, die dem Cache logisch zugeordnet ist, ist die Verarbeitung von Ereignissen. Für sie wird in der Klasse LayoutCache eine Stub-Methode hinzugefügt (C ist ein Parameter der Klassenvorlage): Auch sie kann in einer abgeleiteten Klasse implementiert werden, muss es aber nicht. Die Ereigniscodes werden von der jeweiligen Bibliothek definiert.
Damit diese Methode funktioniert, benötigen wir Makro-Definitionen für die Ereigniserfassung, die denen der Standardbibliothek ähneln und in die Map geschrieben werden, z. B. so: Die neuen Makros leiten die Ereignisse an das Cache-Objekt weiter.
5 Beispiel 2. Dialog mit Steuerelementen
Das Demoprojekt enthält die Klasse CControlsDialog mit den Grundtypen der Standardbibliothek "controls". In Analogie zum ersten Beispiel entfernen wir alle Methoden zu deren Erstellung und ersetzen sie durch ein einziges CreateLayout. Im alten Projekt gab es übrigens 17 Methoden dieser Methoden, die mit Hilfe von komplexen bedingten Operatoren voneinander aufgerufen wurden. In der Cache-Klasse wird der onEvent-Event-Handler deklariert, den wir über die Event-Map anbinden werden. Hier spiegelt der Handler die Nachricht an das übergeordnete Fenster, wo sie wie in den vorherigen Versionen des Beispiels im Informationsfeld angezeigt wird.
Die Styler-Klasse sorgt dafür, dass für alle Elemente die gleichen Felder festgelegt werden, dass alle Schaltflächen eine nicht standardisierte Schriftart haben und dass CEdit mit dem Attribut "schreibgeschützt" in grau angezeigt wird (wir haben eines, aber wenn es hinzugefügt wird, fällt es automatisch unter die allgemeine Einstellung).
Die CBox-Klasse wurde um einen Algorithmus zur Skalierung verschachtelter Elemente auf die Größe des Containers erweitert. Er wird in der AdjustFlexControls-Methode ausgeführt und wird nur wirksam, wenn der spezielle Wert WND_ALIGN_CONTENT in den Container-Ausrichtungsflags angegeben ist. Er ist nicht Teil der Standardaufzählung ENUM_WND_ALIGN_FLAGS. Der Container analysiert die "Controls", um festzustellen, welche davon eine feste Größe haben und welche nicht. "Steuerelemente" mit fester Größe sind solche, für die keine Ausrichtung an den Seiten des Containers (in einer bestimmten Dimension) angegeben ist. Für alle diese "Controls" berechnet der Container die Summe ihrer Größen, subtrahiert sie von der Gesamtgröße des Containers und teilt den Rest proportional auf alle verbleibenden "Controls" auf. Befinden sich beispielsweise zwei "Steuerelemente" im Container, von denen keines einen Anker hat, so teilen sie sich den gesamten Containerbereich zur Hälfte.
Dies ist ein sehr bequemer Modus, der jedoch bei einer Reihe von verschachtelten Containern nicht missbraucht werden sollte - wegen des One-Pass-Algorithmus der Größenberechnung erzeugt die Ausrichtung der internen Elemente auf den Containerbereich, der wiederum an den Inhalt angepasst wird, Unsicherheiten (aus diesem Grund haben die Layout-Klassen ein spezielles Ereignis ON_LAYOUT_REFRESH, das das Fenster an sich selbst senden kann, um die Größenberechnung zu wiederholen).
Das Makro ON_EVENT_LAYOUT_CTRL_DLG ermöglicht Mausklick-Benachrichtigungen für beliebige Schaltflächen der Klasse NotifiableButton (in unserem Fall gibt es nur eine). Das ON_EVENT_LAYOUT_INDEX-Makro sendet das gleiche Ereignis an die Schaltfläche mit dem angegebenen Index im Cache. Dieses Makro konnte jedoch nicht geschrieben werden, da die letzte Zeile des ON_EVENT_LAYOUT_ARRAY-Makros einen Mausklick an ein beliebiges Element im Cache sendet, wenn sein lparam-Bezeichner übereinstimmt.
Im Prinzip könnte man alle Elemente in den Cache verschieben und ihre Ereignisse auf eine neue Art und Weise behandeln, aber die alte Methode funktioniert auch, und man kann sie kombinieren.
Beispiel 3. DynamicForm dynamische Layouts
In diesem letzten Beispiel werden wir ein Formular betrachten, bei dem alle Elemente dynamisch im Cache erstellt werden. Dadurch erhalten wir einige wichtige neue Funktionen.
Wie im vorigen Beispiel unterstützt der Cache das Styling der Elemente. Die einzigen Styling-Einstellungen sind die gleichen markanten Boxen, die es uns ermöglichen, ineinander verschachtelte Container zu sehen und sie nach Wunsch mit der Maus auszuwählen.
Innerhalb der CreateLayout-Methode wird die folgende einfache Schnittstellenstruktur beschrieben. Der Hauptcontainer nimmt, wie üblich, den gesamten Client-Bereich des Fensters ein. Oben befindet sich ein Block mit zwei Schaltflächen: Inject und Export. Der gesamte Platz darunter wird von einem Container eingenommen, der in eine linke und eine rechte Spalte unterteilt ist.
Der Container, in den neue Elemente eingefügt werden sollen, wird zunächst im Cache unter dem Namen "column1" gesucht. Dieser Container wird als erster Parameter bei der Erstellung des injectionPanel-Objekts übergeben. Die Tatsache, dass sich das zu übergebende Element bereits im Cache befindet, wird im Layout-Algorithmus in besonderer Weise berücksichtigt - es wird nicht erneut in den Cache aufgenommen, sondern wie üblich im Containerstapel abgelegt. Auf diese Weise ist es möglich, Elemente zu "alten" Containern hinzuzufügen.
Basierend auf der Auswahl des Benutzers wird ein Objekt des gewünschten Typs mit Hilfe des new-Operators in der getPtr-Hilfsmethode erstellt. Damit die hinzugefügten "Steuerelemente" richtig funktionieren, werden für sie eindeutige Bezeichner nach dem Zufallsprinzip erzeugt. Die spezielle Klasse AutoPtr sorgt für die Löschung des Zeigers beim Verlassen des Codeblocks.
Wenn man zu viele Elemente hinzufügt, werden sie außerhalb der Containergrenzen liegen. Dies geschieht, weil die vorhandenen Containerklassen noch nicht wissen, wie sie korrekt auf einen Überlauf reagieren sollen. In diesem Fall könnten wir z. B. eine Bildlaufleiste einblenden und die Elemente ausblenden, die über die Grenzen hinausragen.
Aber das ist nicht wichtig. Der Sinn dieses Beispiels ist, dass wir dynamische Inhalte erzeugen können, indem wir das Formular anpassen und die erforderliche Füllung und Größe der Container bereitstellen.
Neben dem Hinzufügen von Elementen weiß dieses Dialogfeld auch, wie sie gelöscht werden können. Jedes Element des Formulars kann mit einem Mausklick ausgewählt werden. Die Klasse und der Name des Elements werden im Protokoll angezeigt, und das Element selbst wird durch einen roten Rahmen hervorgehoben. Wenn Sie auf ein bereits ausgewähltes Element klicken, werden Sie in der Dialogbox aufgefordert, das Löschen zu bestätigen, und das Element wird gelöscht, wenn Sie zustimmen. All dies ist in unserer Cache-Klasse implementiert.
Wir können jedes im Cache verfügbare UI-Element löschen, d. h. nicht nur diejenigen, die über die Schaltfläche Inject hinzugefügt wurden. Auf diese Weise können wir zum Beispiel die gesamte linke Hälfte oder die rechte "Radio-Box" löschen. Am interessantesten wird es jedoch, wenn wir versuchen, den oberen Container mit zwei Schaltflächen zu löschen. Das Ergebnis ist, dass die Schaltfläche "Export" ihre Bindung an das Dialogfeld verliert und im Diagramm verbleibt.
Dies geschieht, weil sie das einzige Element ist, das bewusst als automatische und nicht als dynamische Variable beschrieben wird (es gibt eine Instanz von CButton m_button3 in der Formularklasse).
Wenn die Standardbibliothek versucht, Schnittstellenelemente zu entfernen, delegiert sie dies an die Array-Klasse CArrayObj, die ihrerseits den Zeigertyp überprüft und nur Objekte mit POINTER_DYNAMIC entfernt. Es wird also deutlich, dass es für den Aufbau einer adaptiven Schnittstelle, bei der Elemente einander ersetzen oder vollständig gelöscht werden können, wünschenswert ist, eine dynamische Platzierung zu verwenden, und der Cache bietet dafür eine fertige Lösung.
Wenden wir uns nun der zweiten Schaltfläche des Dialogs zu - Exportieren. Wie der Name schon vermuten lässt, ist sie dazu gedacht, den aktuellen Zustand des Dialogs als Textdatei in der betrachteten MQL-Layout-Syntax zu speichern. Natürlich können Sie das Erscheinungsbild des Formulars nur in begrenztem Umfang zu Demonstrationszwecken anpassen, aber allein die Möglichkeit, das Erscheinungsbild in einen vorgefertigten MQL-Code zu entladen, der dann einfach in ein Programm kopiert werden kann, um die gleiche Schnittstelle zu erhalten, ist potenziell eine ziemlich wertvolle Technologie. Natürlich wird nur die Oberfläche übertragen, und der Code für die Ereignisbehandlung oder die allgemeinen Einstellungen des Stylisers müssen unabhängig davon eingefügt werden.
Der Export wird von der Klasse LayoutExporter bereitgestellt, auf die wir nicht im Detail eingehen werden, die Quelltexte sind beigefügt.
- www.mql5.com
Ich habe versucht, in dem obigen Text ein System, ein Konzept, eine Technologie zu finden - ich habe es nicht gefunden. Es ist nicht einmal eine "Skizze" und eher ein Bewusstseinsstrom. Wenn Sie jedoch ständig zu den Code-Beispielen wechseln, werden Sie es nicht bemerken. Das ist schade.
Eigentlich ist dort alles klar für jemanden, der OOP kennt.
Diejenigen, die es nicht kennen, sind selbst schuld.
Für jemanden, der sich mit OOP auskennt, ist das eigentlich ziemlich klar.
Diejenigen, die es nicht kennen, sind selbst schuld.
Das Besondere an dieser Auszeichnungssprache ist, dass sie keinen separaten Interpreter benötigt. Sie ist direkt in den Programmcode eingebaut.
Aber ohne OOP-Kenntnisse können Sie in den Artikeln nicht viel erkennen.
Und da Sie nicht vorhaben, OOP zu studieren, warum sind Sie dann überhaupt hier?
- 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 MQL als Darstellungsmittel für graphische Schnittstellen von MQL-Programmen. Teil 2 :
In diesem Beitrag wird die neue Konzeption zur Beschreibung der Fenster-Schnittstelle von MQL-Programmen anhand der Strukturen von MQL weiter überprüft. Die automatische Erstellung einer GUI auf der Grundlage des MQL-Markups bietet zusätzliche Funktionalität für die Zwischenspeicherung und dynamische Generierung der Elemente und die Steuerung der Stile und neuen Schemata für die Verarbeitung der Ereignisse. Beigefügt ist eine erweiterte Version der Standardbibliothek von Steuerelementen.
Wir können jedes Schnittstellenelement löschen, das im Cache verfügbar ist, d.h. nicht nur diejenigen, die durch die Schaltfläche Einfügen hinzugefügt wurden. Auf diese Weise können Sie z.B. die gesamte linke Hälfte oder die rechte "radiobox" löschen. Am interessantesten wird es, wenn wir versuchen, den oberen Container mit zwei Schaltflächen zu löschen. Das hat zur Folge, dass die Schaltfläche Exportieren nicht mehr an den Dialog gebunden ist und im Diagramm verbleibt.
Editierbares Formular: Hinzufügen und Löschen von Elementen
Dies geschieht, da es das einzige Element ist, das absichtlich als automatische und nicht als dynamische Variable beschrieben wird (in der Formularklasse gibt es eine Instanz von CButton, m_button3).
Wenn die Standardbibliothek versucht, Schnittstellenelemente zu löschen, delegiert sie dies an die Array-Klasse CArrayObj, die wiederum den Zeigertyp prüft und nur Objekte mit POINTER_DYNAMIC löscht. Damit wird deutlich, dass zur Konstruktion einer adaptiven Schnittstelle, bei der Elemente sich gegenseitig ersetzen oder vollständig gelöscht werden können, eine dynamische Platzierung wünschenswert ist, und der Cache bietet hierfür eine fertige Lösung.
Autor: Stanislav Korotky