Diskussion zum Artikel "Orders, Positions und Abschlüsse in MetaTrader 5"
Nach dem Lesen, habe ich nicht die beste Antwort auf diese Frage gefunden.
Wie in den Cache zu laden, zum Beispiel, nur 1 letzte Bestellung aus der Geschichte (um die Aufgabe zu erschweren, lassen Sie die letzte durch Symbol).
Zum Beispiel hat der Advisor eine unterschiedliche Häufigkeit von Aufträgen. Er kann 30 Aufträge pro Tag erteilen und kann mehrere Tage oder Wochen lang "still" sein.
Es gibt Varianten, nach dem Senden eines Auftrags an den Server irgendwo sein Ticket zu speichern und dann diesen Auftrag per Ticket abzurufen - kein Problem. Es ist möglich, sowohl in globalen Variablen als auch innerhalb der EA-Logik zu memorieren. Aber hier ist das Problem, wenn der Expert Advisor sich z.B. von einem anderen Terminal aus mit dem Konto verbindet und kein Ticket der letzten Order hat.
Ich muss die Historie mit Hilfe von HistorySelect laden. Das Enddatum ist mehr oder weniger klar, aber wie berechnet man das Anfangsdatum.
Denn auch in einem kleinen Bereich können mehrere Bestellungen anfallen - kein Problem, aber nicht optimal in Bezug auf das Laden unnötiger Daten. Oder nicht einer von ihnen kann nicht in den Bereich fallen.
Man kann auch einen noch kleineren Datumsbereich nehmen und eine Schleife drehen (den Bereich in die Historie verschieben), um den Cache zu füllen - nicht optimal in Bezug auf die Logik der Arbeit - zusätzliche Schleifen, Abfragen der Historie-Datenbank.
Vorschlag - das Laden der erforderlichen Menge nach Aufträgen/Abschlüssen nach Instrument zu organisieren.
Und mehr: wenn der Zweck des Artikels war, die optimalen Algorithmen des Zugangs zu Aufträgen/Geschäften/Positionen zu zeigen. Ich denke, dass: wenn wir weiter gehen in Bezug auf die Optimierung, wäre es gut, einen Modus des Ladens von Daten aus der Geschichte in den Cache von Feldern zum Beispiel haben, nur Tickets und die Zeit des Sendens der Bestellung an den Server erforderlich sind, warum dann laden alle anderen Daten aus diesem Bereich zu diesen Aufträgen (Magick, Kommentar und vieles mehr).
select * from HistiryOrder where a_date_send>@datestart and a_date_send<@dateend
Diejenigen, die DBMS-Anwendungen entwickeln, sind der Meinung, dass eine solche Abfrage nicht für den produktiven Einsatz zugelassen werden sollte. Es gibt zwar Situationen, in denen alle Daten weiter in einige Aktionen involviert sind, aber das ist eher die Ausnahme als die Regel.
Nach dem Lesen, habe ich nicht die beste Antwort auf diese Frage gefunden.
Wie in den Cache zu laden, zum Beispiel, nur 1 letzte Bestellung aus der Geschichte (um die Aufgabe zu erschweren, lassen Sie die letzte durch Symbol).
Zum Beispiel hat der Advisor eine unterschiedliche Häufigkeit von Aufträgen. Er kann 30 Aufträge pro Tag erteilen und kann mehrere Tage oder Wochen lang "still" sein.
Es gibt Varianten, nach dem Senden eines Auftrags an den Server irgendwo sein Ticket zu speichern und dann diesen Auftrag per Ticket abzurufen - kein Problem. Es ist möglich, sowohl in globalen Variablen als auch innerhalb der EA-Logik zu memorieren. Aber hier ist das Problem, wenn der Expert Advisor sich z.B. von einem anderen Terminal aus mit dem Konto verbindet und kein Ticket der letzten Order hat.
Ich muss die Historie mit Hilfe von HistorySelect laden. Das Enddatum ist mehr oder weniger klar, aber wie berechnet man das Anfangsdatum.
Denn auch in einem kleinen Bereich können mehrere Bestellungen anfallen - kein Problem, aber nicht optimal in Bezug auf das Laden unnötiger Daten. Oder nicht einer von ihnen kann nicht in den Bereich fallen.
Man kann auch einen noch kleineren Datumsbereich nehmen und eine Schleife drehen (den Bereich in die Historie verschieben), um den Cache zu füllen - nicht optimal in Bezug auf die Logik der Arbeit - zusätzliche Schleifen, Abfragen der Historie-Datenbank.
Vorschlag - das Laden der erforderlichen Menge nach Aufträgen/Abschlüssen nach Instrument zu organisieren.
Und mehr: wenn der Zweck des Artikels war, die optimalen Algorithmen des Zugangs zu Aufträgen/Geschäften/Positionen zu zeigen. Ich denke, dass: wenn wir weiter gehen in Bezug auf die Optimierung, wäre es gut, einen Modus des Ladens von Daten aus der Geschichte in den Cache von Feldern zum Beispiel haben, nur Tickets und die Zeit des Sendens der Bestellung an den Server erforderlich sind, warum dann laden alle anderen Daten aus diesem Bereich zu diesen Aufträgen (Magick, Kommentar und vieles mehr).
select * from HistiryOrder where a_date_send>@datestart and a_date_send<@dateend
Diejenigen, die DBMS-Anwendungen entwickeln, sind der Meinung, dass eine solche Abfrage nicht für den produktiven Einsatz zugelassen werden sollte. Es gibt zwar Situationen, in denen alle Daten weiter in einige Aktionen involviert sind, aber das ist eher die Ausnahme als die Regel.
Das Laden und Verarbeiten selbst einer sehr großen Historie wird nicht viel Zeit in Anspruch nehmen. Ein weiterer Punkt ist, dass ein solches Laden bei jedem Tick bereits ein Problem darstellt.
Selbst eine sehr große Historie wird in wenigen Sekunden verarbeitet sein. Die erste Schlussfolgerung ist daher, die Anzahl der vollständigen Ladevorgänge zu reduzieren.
Starten Sie das vollständige Laden der Historie in OnInit(). Merken Sie sich die notwendigen Daten. Dann können Sie die Geschichte in OnTicket() "wie eine Zigeunerin mit der Sonne" spinnen.
Das Laden und Verarbeiten selbst einer sehr großen Historie wird nicht viel Zeit in Anspruch nehmen. Ein weiterer Punkt ist, dass es bereits ein Problem ist, wenn das Laden bei jedem Tick durchgeführt wird.
Selbst ein sehr großer Verlauf wird in wenigen Sekunden verarbeitet. Die erste Schlussfolgerung ist daher, die Anzahl der vollständigen Ladevorgänge zu reduzieren.
Starten Sie das vollständige Laden der Historie in OnInit(). Merken Sie sich die notwendigen Daten. Danach können Sie die Geschichte in OnTicket() "wie eine Zigeunerin mit der Sonne" spinnen.
Genauer gesagt, sollte die Geschichte nur im Initialisierungsblock und an Wochenenden vollständig geladen werden (an Wochenenden sollten Sie auch die Parameter optimieren).
Eine Sache, die mich verwirrte, war, dass der Text eine Menge Warnungen über die Notwendigkeit enthält, die Historie sparsam (mit Bedacht) in den Cache zu laden, aber es gibt kein wirkliches Beispiel dafür, wie diese Aufgabe umgesetzt werden kann. Das hat mich ehrlich gesagt verärgert:
//--- die ursprüngliche Grenze auf vor 3 Tagen setzen datetime start=end-3*PeriodSeconds(PERIOD_D1);
Wird dieser Code (Ansatz) wirklich in einem normalen Expert Advisor verwendet werden? Es sei denn, es handelt sich um eine bestimmte einfache Aufgabe (z.B. Aufträge für mehrere Tage zu finden), und dann - unter Vorbehalt (in diesem Beispiel werden die Wochenenden nicht berücksichtigt, so dass der Code nicht für die Verarbeitung mehrerer Handelstage geeignet ist), hält der Ansatz keiner Kritik stand.
Obwohl es alle Werkzeuge gibt, um wirtschaftliches Laden zu realisieren. Und was mich betrifft, sollte ein Beispiel für eine solche Implementierung im Artikel stehen.
Zum Beispiel, mit dieser Vorlage:
- OnInit() - Laden der gesamten Historie in den Cache, Suche nach der letzten für den Expert Advisor signifikanten Order (z.B. nach Meijik oder nur nach Instrument), Speichern der Zeit in einer Variablen.
- OnTrade() - Aktualisierung der in den Cache geladenen Historie (ausgehend von der gespeicherten Zeit), Aktualisierung der Zeit der letzten Order (wenn eine neue signifikante Order erschienen ist).
- OnTick() - Arbeit mit dem aktuell geladenen Cache oder, falls erforderlich, Laden des Caches ab der gespeicherten Zeit.
Dieser Ansatz erhebt bereits Anspruch auf Stabilität und Universalität. Außerdem - in Bezug auf die Ressourcennutzung könnte es sich als noch sparsamer erweisen als "Auswahl der letzten 3 Tage".
Wie auch immer, nochmals vielen Dank für den Artikel. Solche "Vorgaben von Entwicklern" sind notwendig, sonst wird es keinen normalen Code geben.
Der Artikel gibt ein Beispiel für das Laden der Handelshistorie für einen Tag (ein Code hat ein Beispiel für das Laden der Historie für 3 Tage). Ja, dies ist eine Einschränkung und das Beispiel ist nicht universell. Aber wenn der Leser diese Besonderheit beim Lesen des Artikels versteht, wird er in der Lage sein, selbst zu entscheiden, in welchem Intervall und ab welchem Zeitpunkt er die Handelshistorie in den Cache laden muss.
Der Leser hat die einfachsten Beispiele und Algorithmen erhalten und kann sie nun selbständig in den notwendigen Ereignisverarbeitungsfunktionen anwenden. Er kann selbständig seine eigene Handelshistorie erstellen und deren Initialisierung und Synchronisierung vornehmen usw.
Der Versuch, spezifische Rezepte und Funktionen für die optimale Arbeit mit der Handelshistorie für alle Fälle zu geben, wird mindestens einen weiteren Artikel erfordern. Genauer gesagt, nicht die Beispiele selbst, sondern Ansätze zur Lösung bestimmter Aufgaben. Dieser Artikel sollte dazu dienen, zu verstehen, wie die Handelsfunktionen funktionieren und auf welche Nuancen man achten sollte, um nicht die eigene Zeit mit der Recherche zu verschwenden.
Ich bin sicher, dass nach der Lektüre dieses Artikels alles ganz einfach sein wird.
Können Sie mir sagen, ob es irgendwo eine Beschreibung des Terminalbetriebs im OfLine-Modus gibt? Die Sache ist die, dass ich das Terminal nicht laden konnte, weil die Chartdaten nicht aktualisiert wurden. Ich wollte es auf der Arbeit testen (dort gibt es kein Internet), aber es ging nicht: die Charts warten auf die Aktualisierung, und es gibt kein einziges Symbol im Tester. Im Artikel steht, dass nach dem Starten des Terminals eine Datensynchronisation mit dem Server durchgeführt wird. Aber was passiert, wenn keine Verbindung besteht (eigentlich ist das nicht vorgesehen). Vielleicht ist es sinnvoll, dem Terminal explizit zu sagen, dass es in OfLine arbeiten soll und nicht dieses unglückliche Rad zu drehen. Vielleicht gibt es dann weniger Fehlschläge bei der Arbeit des Testers. Fairerweise muss gesagt werden, dass ich dieses Problem schon lange nicht mehr hatte, aber im Forum wird darüber geklagt. Vielleicht gibt es ein paar Tricks (nun, es gibt eine Datei zu entfernen), um die Situation zu lösen (ich habe es versucht - nichts hat geholfen, bis ich eine Verbindung mit dem Server zu Hause hergestellt habe).
- www.mql5.com
Nach der Übertragung des Terminalkatalogs auf ein neues Gerät wird ein Teil der Konfigurationsdatenbanken (Symbole, Kontoeinstellungen, Transaktionshistorie usw.) speziell gelöscht, da sie mit fest verdrahteten Schlüsseln verschlüsselt sind. Die Historie der Diagramme ist davon nicht betroffen.
Das bedeutet, dass Sie sich nach der Migration mindestens einmal mit einem beliebigen Handelskonto verbinden müssen, damit das Terminal die Marktumgebung anpassen kann. Danach können Sie das Passwort löschen, die Verbindung zum Internet trennen und mit dem Tester offline arbeiten.
Nach der Übertragung des Terminalkatalogs auf ein neues Gerät wird ein Teil der Konfigurationsdatenbanken (Symbole, Kontoeinstellungen, Transaktionshistorie usw.) speziell gelöscht, da sie mit fest verdrahteten Schlüsseln verschlüsselt sind. Die Historie der Diagramme ist davon nicht betroffen.
Das bedeutet, dass Sie sich nach der Migration mindestens einmal mit einem beliebigen Handelskonto verbinden müssen, damit das Terminal die Marktumgebung anpassen kann. Danach können Sie das Passwort löschen, die Verbindung zum Internet trennen und mit dem Tester offline arbeiten.
Ich habe nichts verschoben oder verändert. Ich bin nur mit meinem Laptop zur Arbeit gekommen und wollte den Expert Advisor testen. Ich habe ein Konto und habe natürlich versucht, mich einzuloggen, aber das Protokoll sagt, dass es keine Verbindung zum Server gibt. Vielleicht war es nur ein zufälliger Fehler, aber ich konnte nichts tun.
Ich habe nichts verschoben oder verändert. Ich bin nur mit meinem Laptop zur Arbeit gekommen und wollte den EA testen. Ich habe ein Konto und natürlich habe ich versucht, mich einzuloggen, aber das Protokoll sagt, dass es keine Verbindung mit dem Server gibt. Vielleicht nur ein zufälliger Fehler, aber ich konnte nichts tun.
Bitte stellen Sie einen vollständigen Screenshot des gesamten Terminalfensters zur Verfügung, einschließlich aller Market Watch-, Chart- und Testerzonen.
Versuchen Sie, sich mit dem Konto zu Hause zu verbinden, pumpen Sie die Daten vollständig ab und führen Sie mindestens einen Test durch. Trennen Sie dann die Verbindung zum Internet, starten Sie das Terminal neu und versuchen Sie es erneut.
Bitte stellen Sie einen vollständigen Screenshot des gesamten Terminalfensters zur Verfügung, einschließlich aller Market Watch-, Chart- und Tester-Zonen.
Versuchen Sie, sich mit dem Konto zu Hause zu verbinden, laden Sie die Daten vollständig herunter und führen Sie mindestens einen Test durch. Trennen Sie danach die Verbindung zum Internet, starten Sie das Terminal neu und versuchen Sie es erneut.
Dazu ist nichts erforderlich, da alles wie zuvor funktioniert. Offenbar war es ein versehentlicher Fehler. Zuvor fragte das Terminal nach einer Autorisierung, jetzt startet es ohne. Ich habe es etwa 10 Mal mit und ohne Neustart des Computers getestet. Alles ist in Ordnung, danke.
- 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 Orders, Positions und Abschlüsse in MetaTrader 5 :
Einen robusten Handelsroboter zu erzeugen geht nicht ohne das Verständnis der Mechanismen des MetaTrader 5 Handelssystems. Der Client-Terminal erhält vom Handelsserver Informationen über die Positions, Orders und Abschlüsse. Um diese Daten mittels MQL5 entsprechend verarbeiten zu können, ist ein gutes Verständnis der Interaktion zwischen dem mql5-Programm und dem Client-Terminal unabdingbar.
Autor: MetaQuotes Software Corp.