Erstellen einer grafischen Benutzeroberfläche für MQLs im grafischen Modus. - Seite 10
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
Einseitige Abfrage von μl, Pips, Dateien oder Webanfragen.
Ich bin mir sicher, dass das genau richtig wäre! Wir reden nicht davon, etwas an MT zu schicken. Die Übertragung selbst kann auf jede andere Weise erfolgen. Das Wichtigste ist, MT mitzuteilen, dass eine bestimmte Aktion durchgeführt werden muss. Es ist genau dasselbe wie in der GUI-Bibliothek, die Sie entwickelt haben: alle Colbecs werden über Ereignisse ausgeführt.
Übrigens, zu dieser Bibliothek: Planen Sie, sie zu erweitern und komplett auf Leinwand zu übertragen? Das heißt, das endgültige "Produkt" ist nicht eine Reihe von Diagrammobjekten, sondern ein Gesamtbild.
Und im Zusammenhang mit dll Überprüfung, natürlich würde ich gerne in der Lage sein, dll als eine Ressource in MT enthalten, so dass ich nicht haben, um sie zusammen mit Expert Advisor oder Indikator "ziehen".
Warum bei Dotnet für die Benutzeroberfläche aufhören?
Die Frage bezieht sich nicht so sehr auf die grafische Benutzeroberfläche. Die Schnittstellen können mit MT-Tools leicht erstellt werden. Natürlich ist es ein bisschen kompliziert, und um die Möglichkeiten zu erweitern, muss ich meine eigenen Verarbeitungsklassen erstellen, aber das lässt sich alles lösen. Ich habe angefangen, mit dem Netz zu arbeiten, weil es unmöglich war, einige Algorithmen für die Arbeit mit dem Internet zu implementieren. Es ist ziemlich kompliziert und instabil in C++, sogar in der Muttersprache, ganz zu schweigen von MT. Sobald ich das Netz beherrsche, kann ich auch mit der grafischen Benutzeroberfläche arbeiten, denn im Gegensatz zu MT ist alles dafür vorbereitet. Zu den offenen Fragen der Anwendungsentwicklung in jeder Sprache, und zwar in jeder, da diese Fragen nicht mit dem Netz verbunden sind: 1. Rückmeldung, 2. Verknüpfung von GUI und Diagramm (https://www.mql5.com/ru/forum/103764) - eines der Themen.
Einseitige Abfrage von µl, Pips, Dateien oder Webanfragen.
es ist Ihre Wahl ;-)
Aus der Sicht der Anwendungen sollte es eine Standardmethode geben, um nach dem Aufruf der DLL an MT zu sagen: "Das ist es, was du willst, das ist es, was du bekommst".
Typisches Szenario für lange Berechnungen, Netzwerk-IO - MT ruft DLL auf, DLL erstellt einen Thread und darin wird etwas erledigt. Es muss eine Möglichkeit geben, zu sagen: "Das war's, es wurde berechnet". Ohne sie müssen wir die EAs ständig nach etwas abfragen.
du hast die Wahl ;-)
Aus Sicht der Anwendungen sollte es eine Standardmethode geben, um MT mitzuteilen: "Das ist es, was du willst, das ist es, was du bekommst".
Typisches Szenario für lange Berechnungen, Netzwerk-IO - MT ruft DLL auf, DLL legt einen Thread an, in dem etwas erledigt wird. Es muss eine Möglichkeit geben, zu sagen: "Das war's, es wurde berechnet". Ohne sie müssen wir den EA ständig nach etwas befragen.
Dem stimme ich zu!
Quelle:
Wir können uns bis zum Ende über die Vorzüge der einen oder anderen Entwicklungsumgebung streiten. Aber wozu? Wir alle wissen, dass kein Entwicklungssystem autark ist, weil es spezifische Probleme löst. Jede andere Plug-in-Komponente, die in einer anderen Sprache oder Umgebung entwickelt wurde, kann verwendet werden, um die Fähigkeiten des Programms zu erweitern. Wir müssen es einfach machen, zu kommunizieren. Gehen wir nicht zu weit: dieselben Windows-Bibliotheken, die wir durch Importieren verwenden... ...wir verwenden sie, um die fehlende Funktionalität zu implementieren. Und man kann nicht sagen, dass es nur mit mql umgesetzt wird. ))) Welchen Unterschied macht es also, welche externe Anwendung wir verwenden, um die Möglichkeiten zu erweitern und die gewünschten Ziele zu erreichen? Wieso ist eine selbst geschriebene DLL schlechter als eine Windows-DLL?
Hier ist zum Beispiel ein Artikel: https://www.mql5.com/ru/articles/364
Aber es geht nicht darum, dll komplett abzuschaffen, das wird einfach nie passieren, denn MT hat seine ganz eigenen Aufgaben. In diesem Artikel sind Systembibliotheken vorhanden, egal wie man es betrachtet. Ja, im Gegensatz zu hausgemachten Bibliotheken müssen Sie diese Bibliotheken nicht mit Expert Advisor oder Indikator mitführen...
Nun, was hindert Sie daran, die Möglichkeit zum Kompilieren von DLLs in die Ressourcen des Tools aufzunehmen?
Ja, Sie können es nicht auf den Markt bringen, weil der Markt die Verwendung von dll nicht zulässt, aber es wäre viel bequemer für Ihre eigene Entwicklung.
Wir können uns bis zum Ende über die Vorzüge der einen oder anderen Entwicklungsumgebung streiten. Aber wozu? Wir alle wissen, dass kein Entwicklungssystem autark ist, weil es spezifische Probleme löst. Jede andere Plug-in-Komponente, die in einer anderen Sprache oder Umgebung entwickelt wurde, kann verwendet werden, um die Fähigkeiten des Programms zu erweitern. Wir müssen es einfach machen, zu kommunizieren. Gehen wir nicht zu weit: dieselben Windows-Bibliotheken, die wir durch Importieren verwenden... ...wir nutzen sie, um die fehlende Funktionalität zu implementieren. Und man kann nicht sagen, dass es nur mit mql umgesetzt wird. ))) Welchen Unterschied macht es also, welche externe Anwendung wir verwenden, um die Möglichkeiten zu erweitern und die gewünschten Ziele zu erreichen? Wieso ist eine selbst geschriebene DLL schlechter als eine Windows-DLL?
Hier ist zum Beispiel ein Artikel: https://www.mql5.com/ru/articles/364
Aber es geht nicht darum, dll komplett abzuschaffen, das wird einfach nie passieren, denn MT hat seine ganz eigenen Aufgaben. In diesem Artikel sind Systembibliotheken vorhanden, egal wie man es betrachtet. Ja, im Gegensatz zu hausgemachten Bibliotheken müssen Sie diese Bibliotheken nicht mit Expert Advisor oder Indikator mitführen...
Nun, was hindert Sie daran, die Möglichkeit zum Kompilieren von DLLs in die Ressourcen des Tools aufzunehmen?
Ja, Sie können es nicht auf den Markt bringen, weil der Markt die Verwendung von dll nicht zulässt, aber für Ihre eigene Entwicklung wäre es viel bequemer.
Diese Gedanken und Beiträge sind 10 Jahre alt.
Wenn wir über das Ökosystem sprechen, dann sollten wir einfach die Verwendung jeglicher Importe in MT unterbinden. Aber das tun sie nicht. Schließlich haben sie sich nicht ohne Grund für die Verwendung von Bibliotheksimporten entschieden. Eine Zeit lang konnte MT nicht mit Webanfragen arbeiten, es gab Einschränkungen bei der Arbeit mit Dateien... all dies wurde durch den Import von Bibliotheken ERWEITERT. Das ist ganz offensichtlich und alle Systeme funktionieren so. Selbst jetzt kann MQL nur mit Dateien aus einer Sandbox arbeiten. Es ist nicht so, dass jemand diesen Ansatz in Frage stellt, es ist die Politik des Entwicklers und jeder versteht und unterstützt sie. Wenn Sie aus einer Sandbox herauskommen oder die Registry zum Speichern von Daten verwenden müssen, oder eine Datenbank oder ein Mapping ... dann verwenden Sie bitte Bibliotheken für diesen Zweck. Oder? Das ergibt alles einen perfekten Sinn. Das Tool braucht keine Datenbanken oder irgendetwas anderes... das ist alles nur für Entwickler, weshalb die MQL-Sprache zur Verfügung steht, damit Sie Tools mit beliebiger Funktionalität implementieren können. Und seit es eine Entwicklungsumgebung gibt, ist MT nicht mehr eine Sache für sich. )) Sie müssen nur ... ))))
Diese Art von Gedanken und Beiträgen sind 10 Jahre alt, aber wir sind immer noch hier...
Warum ist das immer noch der Fall?
Alle Möglichkeiten der Interoperabilität gibt es schon seit langem. Die DLL-Unterstützung wurde sogar 2004 eingeführt.
Unsere Sprachen entwickeln sich ständig weiter und werden immer leistungsfähiger und funktionaler. Und das Ökosystem ist leistungsfähiger als alle anderen.