Erstellen einer grafischen Benutzeroberfläche für MQLs im grafischen Modus. - Seite 12
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
Nein, eigentlich nicht. Es gibt keinen Unterschied zwischen einem externen Programm und einem Programm in MT. Die Möglichkeiten sind die gleichen, die Interaktion ist die gleiche.
Sie haben überhaupt nichts erklärt. Wie erhält man Daten aus MT* im Sharpe-Panel?
Ich habe das Feedback über Memory Mapping mit zeitgesteuerter Abfrage durchgeführt. Das Panel hat mir nur unterschiedliche Einstellungen und langsame Berechnungsergebnisse geliefert.
Unwissenheit schafft Vertrauen. Aber Wissen vervielfacht die Sorgen.
Ok, dann mache ich das Panel separat, Kommunikation über Memory Mapping. In den späten 2000er Jahren habe ich das über Rohre gemacht, aber es gefiel mir nicht.
Direkt angeschlossen, habe ich aber nichts Schreckliches bemerkt.
Die COM-Schnittstelle des Terminals wäre cool, auch wenn sie schnell veraltet ist.
Es scheint einfach nicht in die reale Zeit zu passen :-(.
Die COM-Schnittstelle wird wahrscheinlich nicht verfügbar sein.
Aber darf ich fragen, warum sie veraltet ist?
Außerdem wird sie schnell überflüssig.
Die COM-Schnittstelle wird wahrscheinlich nicht verfügbar sein.
Aber darf ich fragen, warum sie veraltet ist?
Außerdem wird sie schnell überflüssig.
es wurde durch .net mit seinen Kommunikationsschnittstellen ersetzt
es wurde durch .net mit seinen Kommunikationsschnittstellen ersetzt
und in COM sind allein die GUIDs eine Menge wert
MS kauft immer noch ungenutzte GUIDs für einen Dollar pro 10 zurück. Wenn Sie noch etwas von früher übrig haben, können Sie einen schönen Gewinn erzielen!
Und in COM sind allein die GUIDs eine Menge wert
MS kauft immer noch ungenutzte GUIDs für einen Dollar pro Zehner zurück. Wenn Sie noch etwas von früher übrig haben, können Sie damit eine Menge Geld verdienen!
Ich habe noch ein paar herumliegen :-) Sie können sie an MS schicken.
066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb
Wenn es noch etwas gibt, kann ich es vielleicht finden.
Kolleginnen und Kollegen. Ich denke, dass der Streit darüber, welche Entwicklungsumgebung besser und welcher Code schneller ist, überhaupt keinen Sinn hat. Das ist alles Geschmackssache und hängt von den zu lösenden Aufgaben ab. Unabhängig von der Entwicklungsumgebung haben wir immer noch Probleme mit der Interaktion zwischen einer externen Anwendung und einem MetaTrader-Tool. Lassen Sie uns ein einfaches Beispiel betrachten. Sie haben einen Algorithmus mit komplexen mathematischen Berechnungen in eine native dll implementiert. Sie haben die erforderlichen Parameter vom MT-Tool an diese Bibliothek übergeben und die Berechnung gestartet, das Tool hat seine Arbeit fortgesetzt, bis die Berechnung abgeschlossen war. Und noch einmal: Dieses Problem hängt nicht von der Entwicklungsumgebung ab!
Ich sehe mehrere Möglichkeiten:
1. Die Möglichkeit, von außerhalb des Programms die Methode OnChartEvent aufzurufen, z.B. mit der PostMessage
2. Hinzufügen einer neuen Methode zu МТ tools, wie von Renat angeboten: OnExternal, mit Angabe des Ereignistyps oder allgemein der übertragenen Daten, d.h. in dieser Methode können Sie die Daten zurückgeben
3. Implementierung in MT-Tools von winsocket. Dies ähnelt dem zweiten Punkt, ermöglicht es dem MT-Tool jedoch, sich mit einem bestimmten Port zu verbinden, um auf Daten zu warten.
Wenn der erste und zweite Punkt eine Interaktion auf der Ebene einer einzelnen Maschine ermöglichen, wird der dritte Punkt MT-Tools mit Netzwerkkommunikation bereitstellen.
Hier ist ein Beispiel:https://www.mql5.com/ru/articles/2599
Aber auch hier haben Sie das Problem, dass Sie überprüfen müssen, ob die Daten auf der Steckdose ständig verfügbar sind.
Das Rückrufproblem bleibt also in allen Fällen bestehen und ist nicht gelöst.
Die Timer-Überwachung ist keine Lösung, sondern eine Krücke. Ja, in Ermangelung anderer Möglichkeiten lösen wir das Problem jetzt auf diese Weise.
Wenn die Entwickler eine Lösung für diese Probleme auf der Plattformebene implementieren würden, wäre es nicht notwendig, auf die API des Terminals zuzugreifen. Schließlich wird es nicht wegen des guten Lebens verlangt, sondern weil es keine vollwertige Interaktion zwischen MT und den zu erstellenden Anwendungen gibt. Und ich wiederhole: Dieses Problem besteht unabhängig von der gewählten externen Anwendungsentwicklungsumgebung.
Informationen über die Möglichkeit der Nutzung von Netzbibliotheken )))https://www.mql5.com/ru/forum/13388
Das Thema ist im Prinzip sehr alt. Die Entwickler selbst kündigten einst die Möglichkeit an, ohne Schwierigkeiten mit Netzbibliotheken zu arbeiten... Seitdem ist viel Wasser geflossen, aber die Frage bleibt ungelöst...
Oder hier, eine Nachricht von Renat selbst:https://www.mql5.com/ru/forum/3153/page2#comment_298866
https://www.mql5.com/ru/forum/3153/page2#comment_298892
Kolleginnen und Kollegen. Ich denke, dass der Streit darüber, welche Entwicklungsumgebung besser und welcher Code schneller ist, überhaupt keinen Sinn hat. Es ist alles Geschmackssache und hängt von den zu lösenden Aufgaben ab. Unabhängig von der Entwicklungsumgebung haben wir immer noch Probleme mit der Interaktion zwischen einer externen Anwendung und einem MetaTrader-Tool. Lassen Sie uns ein einfaches Beispiel betrachten. Sie haben einen Algorithmus mit komplexen mathematischen Berechnungen in eine native dll implementiert. Sie haben die erforderlichen Parameter vom MT-Tool an diese Bibliothek übergeben und die Berechnung gestartet, das Tool hat seine Arbeit fortgesetzt, bis die Berechnung abgeschlossen war. Und auch dieses Problem ist unabhängig von der Entwicklungsumgebung!
Ich sehe mehrere Möglichkeiten:
1. Die Möglichkeit, von außerhalb des Programms die Methode OnChartEvent aufzurufen, z.B. mit der PostMessage
2. Hinzufügen einer neuen Methode zu МТ tools, wie von Renat angeboten: OnExternal, mit Angabe des Ereignistyps oder allgemein der übertragenen Daten, d.h. in dieser Methode können Sie die Daten zurückgeben
3. Implementierung in MT-Tools von winsocket. Dies ähnelt dem zweiten Punkt, ermöglicht es dem MT-Tool jedoch, sich mit einem bestimmten Port zu verbinden, um auf Daten zu warten.
Wenn der erste und zweite Punkt eine Interaktion auf der Ebene einer einzelnen Maschine ermöglichen, wird der dritte Punkt MT-Tools mit Netzwerkkommunikation bereitstellen.
Hier ist ein Beispiel:https://www.mql5.com/ru/articles/2599
Aber auch hier haben Sie das Problem, dass Sie überprüfen müssen, ob die Daten auf der Steckdose ständig verfügbar sind.
Das Rückrufproblem bleibt also in allen Fällen bestehen und ist nicht gelöst.
Die Timer-Überwachung ist keine Lösung, sondern eine Krücke. Ja, in Ermangelung anderer Möglichkeiten lösen wir das Problem jetzt auf diese Weise.
Wenn die Entwickler eine Lösung für diese Probleme auf der Plattformebene implementieren würden, wäre es nicht notwendig, auf die API des Terminals zuzugreifen. Schließlich wird es nicht wegen des guten Lebens verlangt, sondern weil es keine vollwertige Interaktion zwischen MT und den zu erstellenden Anwendungen gibt. Und ich wiederhole: Dieses Problem besteht unabhängig von der gewählten externen Anwendungsentwicklungsumgebung.
Ich werde über die Überwachung und Abfrage hinzufügen, nur nicht jeder weiß es - um zu vermeiden, Ruckeln DLL bei jeder Abfrage, können Sie int[] für "Sharing"-Flags haben. Innerhalb der DLL alle Zugriffe auf sie als __atomic__ .
Im Prinzip funktioniert das und ist ziemlich ressourcenschonend, aber man muss sich darauf verlassen, dass auf der MQL-Seite Inkrement/Dekrement auch atomar sind und der Optimierer keine Annahmen über Werte macht.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Um die Dinge wirklich gut zu machen, würden atomare (flüchtige?) Attribute und eine Reihe geeigneter Primitive ausreichen. Meiner Meinung nach ist es einfacher, als einen neuen Mechanismus in das System einzubauen und das bestehende DLL-Protokoll nicht zu ändern.
Ich werde über die Überwachung und Abfrage hinzufügen, nicht jeder weiß, über sie - nicht zu DLL mit jeder Umfrage zu stören, können Sie int[] für "Sharing"-Flags erstellen. Innerhalb der DLL alle Zugriffe auf sie als __atomic__ .
Im Prinzip funktioniert das und ist ziemlich ressourcenschonend, aber man muss sich darauf verlassen, dass auf der MQL-Seite Inkrement/Dekrement auch atomar sind und der Optimierer keine Annahmen über Werte macht.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Um die Dinge wirklich gut zu machen, würden atomare (flüchtige?) Attribute und eine Reihe geeigneter Primitive ausreichen. Meiner Meinung nach ist es einfacher, als einen neuen Mechanismus in das System einzubauen und das bestehende DLL-Protokoll nicht zu ändern.
Maxim, inwiefern ist diese Lösung besser? Denn um den Status einer Flagge zu überprüfen, muss sie auch in MQL periodisch überprüft werden. Es stellt sich also heraus, dass man überall, wo man hinschaut, ständig Veränderungen des Zustands von etwas überwachen muss, um zu verstehen, dass es Zeit ist, die Daten abzuholen. Und dieses Fragment kann in der dll selbst gespeichert und dort überprüft werden - so mache ich es auch. In Ihrem Beispiel haben wir einen impliziten Aufruf an die DLL, um den Status der Flagge zurückzugeben.