![MQL5 - Sprache von Handelsstrategien, eingebaut ins Kundenterminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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 kann versucht werden, dies zu ermitteln.
Wenn es sich um Minuten handelt, können Sie die Zeit des letzten Balkens mit TimeCurrent() vergleichen. Wenn es nicht M1 ist, können Sie iTime(_Symbol,PERIOD_M1,0) abfragen und mit TimeCurrent() vergleichen.
Sie können den Geldkurs oder den letzten Kurs (je nach Symbol) mit dem Schlusskurs des letzten Balkens vergleichen. Sie können SymbolInfoTick direkt nach dem aktuellen Symbol fragen. Zusätzlich zu Bid und Last gibt es auch die Tick-Zeit
Danke, wenigstens ein paar Informationen darüber, wo und wie man nach Fehlern suchen kann, wenn etwas schief gelaufen ist
aber ich denke, dass alle die gleiche eingebettete Funktion benötigen, um den Status zu überprüfen, oder besser noch wäre es ein Flag, wie int _LastError, die die Anzahl der verpassten Ticks speichern würde, wäre es praktisch, wenn OnCalculate() aufrufen - in komplexen Berechnungen sofort zurückkehren, um das Symbol Stream freigeben
Danke, wenigstens ein paar Informationen darüber, wo und wie man nach Fehlern suchen kann, wenn etwas schief gelaufen ist
aber ich denke, dass alle die gleiche eingebettete Funktion benötigen, um den Status zu überprüfen, oder besser noch, es wäre ein Flag, wie int _LastError, die die Anzahl der verpassten Ticks speichern würde, wäre es praktisch, wenn OnCalculate() aufrufen - in komplexen Berechnungen sofort zurückkehren, um das Symbol Stream freigeben
gedacht, gegrübelt.... Das ist keine Lösung. Was wird aus dem Wissen über verpasste Ticks (Slava sagt, dass garantiert ist, dass der Indikator ALLE Ticks empfängt, und diese Tatsache führt dazu, dass nicht nur MQL-Programme, sondern sogar das Client-Terminal hängen)? auf jeden Fall müssen diese Ticks gesammelt und verarbeitet werden, und das bedeutet, wenn wir einen Tick verpasst haben, warum plötzlich hoffen, dass es beim nächsten Mal möglich sein wird? - Es ist ein Teufelskreis.
Ich habe gedacht... vielleicht sollten die Entwickler etwas ähnliches wie die Ausnahmen einführen? Das Eintreffen eines neuen Ticks sollte alle Operationen, Berechnungen im Indikator in diesem Moment unterbrechen, und jede Standard-MQL-Funktion sollte bei ihrer Ausführung einen Fehler zurückgeben, wenn zu diesem Zeitpunkt ein neuer Tick kommt ... Dann wird die Arbeit mit dem Indikator klar, bequem und vorhersehbar. Für die anderen Programmtypen (Skripte, Expert Advisors) ist es fast unnötig.
Und alle möglichen Überprüfungen von Häkchen im Indikator auf ihre Relevanz - das ist, gelinde gesagt, nicht die Lösung.
Wir haben eine Idee für Indikatoren, die das #property tester_everytick_calculate Flag nicht enthalten, um den Berechnungsmodus auf der Basis des Empfangs eines Pakets von Ticks, anstatt auf jedem Tick, einzuschließen.
Damit wird das Problem der langsamen Indikatoren radikal gelöst, wobei die Möglichkeit der garantierten Verarbeitung jedes Ticks für einige Indikatoren erhalten bleibt.
Wir haben eine Idee für Indikatoren, die das #property tester_everytick_calculate Flag nicht enthalten, um den Berechnungsmodus basierend auf dem Tick-Pack-Empfang, anstatt auf jedem Tick, einzuschließen.
Dadurch wird das Problem der verzögerten Indikatoren drastisch gelöst, wobei die Möglichkeit der garantierten Verarbeitung jedes Ticks für einige Indikatoren erhalten bleibt.
Sie können also einen sehr schnellen Indikator mit einem solchen Design haben?
Wenn ja, ist das eine gute Nachricht!
Wir haben eine Idee für Indikatoren, die das #property tester_everytick_calculate Flag nicht enthalten, um den Berechnungsmodus auf der Basis des Empfangs eines Pakets von Ticks, anstatt auf jedem Tick, einzuschließen.
Damit wird das Problem der langsamen Indikatoren radikal gelöst, wobei die Möglichkeit der garantierten Verarbeitung jedes Ticks für einige Indikatoren erhalten bleibt.
Und wenn Sie eine Standardfunktion zum Abrufen eines synchronisierten Mehrwährungs-Arrays erstellen, wird das ein echter Urlaub.
Wir haben eine Idee für Indikatoren, die das #property tester_everytick_calculate Flag nicht enthalten, um den Berechnungsmodus auf der Basis des Empfangs eines Pakets von Ticks, anstatt auf jedem Tick, einzuschließen.
Damit wird das Problem der langsamen Indikatoren radikal gelöst, wobei die Möglichkeit der garantierten Verarbeitung jedes Ticks für einige Indikatoren erhalten bleibt.
Gute Idee!
Und vorzugsweise sollte es standardmäßig ohne jede#Eigenschaft funktionieren.
Wenn jemand es anders braucht, dann soll er#property einsetzen.
Aber es gibt noch eine andere Art von Problemen - in Echtzeit, bei jedem Tick. In diesem Fall haben Sie entweder Zeit, Berechnungen nach dem Tick durchzuführen oder nicht, und dann ist die Handelslösung irrelevant (es gibt keinen dritten Weg). Deshalb gibt es nur einen richtigen Weg, das Problem zu lösen: alle laufenden Berechnungen unterbrechen und den Fehler zurückgeben, wenn ein neuer Tick kommt. Ansonsten kann man die Echtzeit vergessen. Die Zecken werden immer schneller, und es ist noch ein weiter Weg, so dass man für die Zukunft planen muss, ganz zu schweigen von der Tatsache, dass es unmöglich ist, in der Gegenwart alle Zecken ohne Zeitverzögerung zu verarbeiten.
Die Lösung für den Erhalt von Ticks in Paketen ist gut und wahrscheinlich nicht sehr teuer, wenn wir keine Echtzeit benötigen (aber es ist unklar, wie EAs mit Indikatoren arbeiten werden, die mit "gestrigen" Preisen arbeiten, aber egal).
Aber es gibt noch eine andere Art von Aufgaben - in Echtzeit, bei jedem Ticken. Entweder hat man nach dem Erhalt eines Ticks Zeit, Schätzungen vorzunehmen, oder man hat keine Zeit, und die Handelslösung ist irrelevant (es gibt keine dritte Alternative). Deshalb gibt es nur einen richtigen Weg, das Problem zu lösen: alle laufenden Berechnungen unterbrechen und den Fehler zurückgeben, wenn ein neuer Tick kommt. Ansonsten kann man die Echtzeit vergessen. Die Zecken werden immer schneller, und es ist noch ein weiter Weg, so dass man für die Zukunft planen muss, ganz zu schweigen von der Tatsache, dass es unmöglich ist, in der Gegenwart alle Zecken ohne Zeitverzögerung zu verarbeiten.
Der größte Teil der Indikatoren EAs arbeiten mit geschlossenen bar[1], das ist, warum das Überspringen von Ticks keine Rolle, es ist tatsächlich für Indikatoren arbeiten mit Ticks, aber es gibt nicht viele von ihnen, für sie ist es möglich,"#property tester_everytick_calculate" zuzuweisen.
Und noch einmal: Wenn Sie Super-Ticks benötigen, brauchen Sie dafür keinen Indikator, denn all dies kann in den Code des Expert Advisors geschrieben werden. Es ist also nicht sinnvoll, die gesamte Arbeit des Indikators um jedes Tick zu verlangsamen.
Wir warten auf"#property tester_everytick_calculate".
Der größte Teil der Indikatoren EAs arbeiten mit geschlossenen bar[1], das ist, warum das Überspringen von Ticks keine Rolle, es ist tatsächlich für Indikatoren arbeiten mit Ticks, aber es gibt nicht viele von ihnen, für sie ist es möglich,"#property tester_everytick_calculate" zuzuweisen.
Und noch einmal: Wenn Sie Super-Ticks benötigen, brauchen Sie dafür keinen Indikator, denn all dies kann in den Code des Expert Advisors geschrieben werden. Es ist also nicht sinnvoll, die Arbeit des Indikators für jeden Tick zu verlangsamen.
Warten auf"#property tester_everytick_calculate"