Bibliotheken: Kalender - Seite 2
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
In allen HTML-Kalendern (einschließlich des Standardkalenders und des Terminals) ist das Tripel (Ist, Prognose, Vorherige) = (Ist, Prognose, Überarbeitet). Daher können Sie das Feld Überarbeitet in der Historie nicht verwenden, bis das nächste entsprechende Ereignis eintritt. Die anderen Felder können verwendet werden.
Ich habe noch nicht mit der lokalen Kalender-API gearbeitet - ihre Dokumentation lässt viel zu wünschen übrig (es wäre also eine logischere Bibliothek erforderlich). Ist es nicht möglich, ein Array von Ereignisänderungen ab der angegebenen change_id abzufragen? Aus irgendeinem Grund ist es nicht zeitbasiert. Leider gelten diese Fragen eher für den Kalender selbst und nicht für die Bibliothek, aber da die Bibliothek auf dem Kalender aufbaut, bleiben sie auch für diesen offen. Das Problem mit den Änderungen ist, dass ich in meiner bisherigen Praxis der Verwendung externer Kalender festgestellt habe, dass einige Felder sozusagen rückwirkend angepasst werden können, und deshalb müssen wir unter Berücksichtigung der Chronologie der Änderungen testen.
Ich verstehe nicht, wie previous=revised(die MqlCalendarValue-Struktur hat alle 4 Felder: actual, prev, revised, forecast) und warum man revised nicht auf history verwenden kann - imho kann revised (wenn previous revised ist) zu jedem Zeitpunkt zwischen der letzten Ereignisveröffentlichung und der nächsten erscheinen, d.h. nur auf history.
Ich habe nicht mit dem lokalen Kalender-API gearbeitet - seine Dokumentation lässt viel zu wünschen übrig (daher eine logischere Bibliothek benötigt werden würde). Ist es nicht möglich, ein Array von Ereignisänderungen ab der angegebenen change_id abzufragen? Es ist nicht zeitgebunden aus irgendeinem Grund.
Jede Änderung im Kalender hat ihre eigene change_id. Sie können also alle Änderungen ab einer bestimmten change_id bis zur aktuellen change_id abfragen.
Ich verstehe nicht, wie previous=revised(die MqlCalendarValue-Struktur hat alle 4 Felder: actual, prev, revised, forecast) und warum man revised nicht für history verwenden kann - imho kann revised (wenn previous revised ist) zu jedem Zeitpunkt zwischen der letzten Ereignisfreigabe und der nächsten erscheinen, d.h. nur für history.
In Kalendern können Sie nur drei Felder für ein Ereignis sehen. In der API sind es vier. Überarbeitet wird der jüngste Wert, der auch eine Woche nach dem Eingang des Ereignisses liegen kann. Dies ist der Grund für das etwas logische Verbot der Verwendung von Revised in Backtests.
Ich sehe eher enge Szenarien der praktischen Kalenderverwendung. Wenn Sie Ihre eigenen Optionen haben - sprechen Sie sie an. Vielleicht hat die Bibliothek eine API, die für Ihre Szenarien nicht optimal ist. Dann werden wir darüber nachdenken.
Das Thema scheint recht neu zu sein.
GMT-Funktionen sind vorhanden, aber sie scheinen nicht verwendet zu werden. Ich weiß nicht, ob sie dort gebraucht werden.
Sie sind für die Zukunft gedacht. Da der Kalender an die Serverzeit gebunden ist, kann er von außen übernommen werden.
Ich sehe eher knappe Szenarien für die bequeme Nutzung des Kalenders. Wenn Sie Ihre eigenen Varianten haben - sprechen Sie sie an. Vielleicht hat die Bibliothek eine API, die für Ihre Szenarien nicht optimal ist. Dann werden wir darüber nachdenken.
Das Thema scheint recht neu zu sein.
Nach der Beschreibung der MT-Kalenderfunktionen zu urteilen, sollten wir so etwas wie Observer mit Überwachung aller Änderungen und der Ankunft neuer Ereignisse per Abonnement und Änderungen in Actual, Revised schreiben.
Dann denke ich, könnte es praktisch sein.
Nach der Beschreibung der MT-Kalenderfunktionen zu urteilen, sollten wir so etwas wie Observer mit Überwachung aller Änderungen und der Ankunft neuer Ereignisse im Abonnement sowie Änderungen der Werte von Actual, Revised.
Terminologisch verstehe ich das nicht.
Terminologisch gesehen, verstehe ich das nicht.
https://refactoring.guru/ru/design-patterns/observer
https://refactoring.guru/ru/design-patterns/observer
Danke. Wenn wir über OnCalendar sprechen, wird eine Art von Simulation über change_id Mechanismus sein.
Es ist besser, die Anwendungsszenarien mit schematischen Code zu demonstrieren, natürlich.
Danke. Wenn wir über OnCalendar sprechen, wird es eine Simulation über den change_id-Mechanismus geben.
Sie sprechen von der Simulation von Kalenderereignissen, die in MT5 in Zukunft eingeführt werden könnte.
Ich bezog mich auf den Mechanismus des Abonnements von Ereignissen, die von Interesse sind, einschließlich der Änderung von Revised, da sich diese jederzeit ändern kann.
Wenn Sie mit dem Observer-Muster nicht vertraut sind, empfehle ich Ihnen, den Link von Andrei zu lesen.
Die Essenz der Idee ist kurz gesagt, dass, zum Beispiel:
Ich muss alle EUR-Ereignisse mit einer Wichtigkeit von mehr als 3 für den Handel kennen. Ich wende mich an einen Provider (ein Objekt der Klasse , die Abonnements und Alerts verwaltet, auch Publisher genannt, kann ein einzelnes sein), abonniere.
Und dann überwacht der Anbieter selbst alle Änderungen bei den Ereignissen, an denen ich interessiert bin, und benachrichtigt mich (durch Aufruf der Methode der Ereignisverarbeitung mit den entsprechenden Informationen).
Der Kern der Idee ist kurz gesagt, dass, zum Beispiel:
Ich muss alle EUR-Ereignisse mit einer Wichtigkeit von mehr als 3 für den Handel kennen. Ich kontaktiere einen Anbieter (ein Objekt der Klasse , die Abonnements und Alerts verwaltet, auch Publisher genannt, kann einfach sein), abonniere.
Und dann überwacht der Anbieter selbst alle Änderungen in den Ereignissen, an denen ich interessiert bin, und benachrichtigt mich (durch Aufruf der Methode der Ereignisverarbeitung mit den entsprechenden Informationen).
Kein benutzerdefiniertes Objekt kann sich ohne einen entsprechenden Aufruf selbst überprüfen. D.h. es muss vom Benutzer in seinem Code geschrieben werden. Wenn er es geschrieben hat, dann macht er die Verarbeitung selbst.
Der change_id-Mechanismus ist sehr einfach: Sie führen die Refresh-Methode aus. Danach erhält man die Daten, was und wo aktualisiert wurde in der Liste der Ereignisse, die man erstellt hat.