Diskussion zum Artikel "MQL als Darstellungsmittel für graphische Schnittstellen von MQL-Programmen. Teil 1" - Seite 3
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Es wird kein XML geben. Das Ziel ist es, ohne MQL auszukommen. Das Ziel ist es, ein MVP-Level Markup-System "native" zu MQL zu machen - ohne Schnickschnack, aber funktional und erweiterbar genug für diejenigen, die es brauchen. Es wird möglich sein, nicht auf die interne Struktur einzugehen. Es ist nur so, dass es in der Regel besser ist, eine Beschreibung des Konzepts und des Geräts zu haben, als keine zu haben.
...
Es gibt in der Tat keine Benutzer von grafischen Bibliotheken, Auszeichnungssprachen oder visuellen Editoren (vielleicht gibt es sie, aber man sieht sie nicht). Es gibt Leute, die das lernen wollen. Wenn es in den Artikeln kein Konzept für die Auszeichnungssprache gibt, sind sie bedeutungslos. Schreiben Sie ein Konzept. Viel Glück!
Es gibt keine Benutzer von grafischen Bibliotheken, Auszeichnungssprachen oder visuellen Editoren (vielleicht gibt es sie, aber man sieht sie nicht). Es gibt Leute, die versuchen zu lernen. Wenn Artikel kein Konzept für eine Auszeichnungssprache haben, sind sie sinnlos. Schreiben Sie ein Konzept. Viel Glück!
Bedeutung. Es gibt keine Sprache in dem Artikel, nicht einmal das Konzept selbst?
Was bedeutet das? Nicht, dass es in dem Artikel keine Sprache gibt, nicht einmal der Begriff selbst fehlt?
Der Autor hat nicht beschrieben, wie die Auszeichnungssprache funktioniert. Stellen Sie die Frage"Wie funktioniert die Auszeichnungssprache?" und finden Sie eine ausführliche Antwort in dem Artikel. Die gibt es nicht.
Der Autor hat nicht beschrieben, wie die Auszeichnungssprache funktioniert. Stellen Sie die Frage"Wie funktioniert die Auszeichnungssprache?" und finden Sie eine ausführliche Antwort in dem Artikel. Es gibt keine.
Wahrscheinlich wird sie in der nächsten Ausgabe zu finden sein.
Wahrscheinlich wird es in der nächsten Ausgabe erscheinen.
Ich dachte auch, es würde in der nächsten Ausgabe stehen. Wir sind hier keine Einfaltspinsel. Jeder versteht das.
Es wird kein XML geben. Das Ziel ist es, ohne MQL auszukommen. Das Ziel ist es, ein MVP-Level Markup-System "native" zu MQL zu machen - ohne Schnickschnack, aber funktional und erweiterbar genug für diejenigen, die es brauchen. Es wird möglich sein, nicht auf die interne Struktur einzugehen. Es ist nur so, dass es in der Regel besser ist, eine Beschreibung des Konzepts und des Geräts zu haben, als keine zu haben.
Ich bin auch nicht verrückt nach der Standardbibliothek, aber es gibt nicht viel Auswahl, also ist es (im Moment) ein optimaler Kompromiss zwischen den wenigen sehr kleinen und super ausgefallenen Bibliotheken, zu denen ich sowieso große Fragen habe.
Die vermeintlichen Koryphäen in Sachen Programmierung und GUI-Erstellung, die sich aufgrund naiver Basteleien als solche deklariert haben, sollen doch bitte in einem eigenen Thread ihre Hattrickkünste unter Beweis stellen.
Auf wen genau beziehen Sie sich? Zumal es im Plural steht, und wir sind hier nicht viele. Wenn es im Singular wäre, hätte ich gedacht, es ginge um Peter... aber es ist der Plural. Das wirft Fragen auf.
Warum sagst du nicht einfach deinen Vornamen? Damit keine unnötigen Fragen aufkommen. Oder kannst du nicht einfach in die Luft treten?
Zum Thema des Artikels. Zum fünften Mal habe ich das Ganze noch einmal sorgfältig, neutral und so objektiv wie möglich gelesen. Und hier ist die Quintessenz:
1. Zu Beginn des Artikels diskutiert der Autor klar und deutlich mit dem Leser die Problematik der GUI-Relevanz in Programmen. Er berichtet über die verfügbaren grafischen Werkzeuge von MQL - MT-Objekte, Bibliotheken und sogar einen View-Editor. Behauptet, dass GUI eher notwendig ist als nicht. Dies ist ein klarer und angenehmer Teil des Artikels.
2. Die Beschleunigung beginnt. Der Autor gibt ein Beispiel für Standardbibliothekscode und kritisiert ihn zu Recht - er ist lang, unbequem, ineffizient beim Aufbau einer GUI. Die Sympathien sind auf seiner Seite.
3. Dann geht der Autor zur Diskussion von GUIs in anderen Sprachen über, wo er richtig anmerkt, dass die Beschreibung des Layouts klugerweise vom Programmcode getrennt ist und einen unabhängigen Zweig darstellt, der die routinemäßige Gestaltung von Schnittstellen vereinfacht. Er zählt die Vorteile auf. Diesmal verwendet der Autor allgemeine Formulierungen und Verweise auf Literatur, .Net-Plattform, Android, XML.... Er sagt, dass dort, wie auch hier, alles in "einem Flakon" ist und die Hierarchie sichtbar ist, und auch "Einzelcontroller" definiert sind. Er klärt nicht auf, er macht einfach weiter. Für den Unaufgeklärten endet die Klarheit und alles versinkt im Nebel. Wo, was, warum....
4- Der Autor "fliegt" und der Dialog mit dem Leser verwandelt sich in einen Hochgeschwindigkeitsmonolog. Die klare Reihenfolge der Darstellung verschwindet: Fragen/Themen/Lösungen/Beispiele/Codes - alles wird durcheinander geworfen. Für Telepathen ist das natürlich nicht schwer, aber der Rest von uns hat es schwer. Es hat den Anschein, als ob der Autor sich im Eiltempo Lösungen für eine neue Sprache ausdenkt und alles bis zum Ende des Artikels fertigstellen will. So nach dem Motto: "Mischen Sie sich nicht ein, ich mache das schon! In einem hektischen Rhythmus huschen Gedankenfetzen, Codes, Namen von Variablen und Methoden (die vielleicht jemandem bekannt sind...) vorbei. Die Sprünge werden immer häufiger und mein Kopf kommt mit der Suche nach Verbindungen zwischen den Sätzen nicht mehr zurecht. Es wird wirklich schwer zu lesen.
5. Der Dialog mit dem Leser ging nach den ersten beiden Kapiteln verloren und auch das weitere Lesen brachte mir keine Klarheit. Obwohl ich mich sehr angestrengt habe. Es blieb die Frage: "Und was genau schlägt der Autor vor?".
Ich schloss den Artikel und konnte mich an nichts mehr erinnern außer an das Beispiel mit den Flecken und die ersten Absätze. Alles andere löste sich in einem Nebel auf.
Hoffentlich wird der Autor in der nächsten Ausgabe den Dialog mit dem Leser fortsetzen und die Erzählstruktur bis zum Ende des Artikels beibehalten.
Vielen Dank!
Dmitry Fedoseyev, obwohl beleidigend, sehr lustiges Video einfügen. Ich habe lange Zeit gelacht. Als ich las, was Sie hervorgehoben haben, wurde mir klar, dass es wirklich dumm aussah. Es wäre richtiger zu sagen, nicht umgeschrieben, sondern verbessert und ergänzt. Ich habe in den fünf Jahren Ihrer Anwesenheit auf dieser Website viele Ihrer Artikel gelesen, und ich bezweifle nicht, dass Ihr Wissen viel größer ist als das meine, aber ich stimme nicht mit Ihnen überein, dass es keinen Bedarf für OOP in Express-Writing gibt. Denn in komplexen Programmen, die grafische Schnittstellen verwenden, mehrere TS in einem EA kombinieren, Statistiken führen usw., hilft OOP sehr, den Code des Programms besser zu strukturieren, und Design Patterns (obwohl ich noch ganz am Anfang ihres Studiums stehe) erhöhen die Leistung von OOP um ein Vielfaches. Das bedeutet natürlich nicht, dass man es in eine kleine EA schieben sollte, wo man mit gewöhnlichen Prozeduren auskommt und die Geschwindigkeit beim Schreiben um ein Vielfaches höher ist. Wenn es interessant ist, werde ich ein Beispiel beschreiben, bei dem ich OOP und eine Vorlage verwendet habe und wie es mein Leben vereinfacht hat. Und wenn es nicht zu schwierig ist, Dmitry, könnten Sie Ihre Worte"und noch mehr bei der Erstellung eines Analogons eines Delegaten mit OOP, während es Zeiger auf Funktionen gibt" an einem Beispiel zeigen. Oder in welchem Artikel kann man Informationen über Funktionszeiger finden. Vielen Dank im Voraus.
Alles steht in der Dokumentation, studieren Sie sie, benutzen Sie sie.