#include <fxsaber\Calendar\Calendar.mqh> // https://www.mql5.com/it/code/32430 int OnInit() { return(!EventSetTimer(1)); } void OnTimer() { CALENDAR Calendar; string Currencies[2]; // Ottenere le valute del carattere corrente. Currencies[0] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_BASE); Currencies[1] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_PROFIT); // Ha selezionato i prossimi eventi importanti in base alle valute simbolo. Calendar.Set(Currencies); Comment(Calendar.ToString(0, 5, true)); // Stampateli. }
La probabilità di perdere notizie importanti si riduce notevolmente.
Una tale chiamata da zero viene eseguita in 0,6 ms. Naturalmente, è possibile ridurre a zero il consumo.
Ilcalendario degli eventi è scritto molto più in là nel tempo. Pertanto, è possibile utilizzare un promemoria anche nella MT4 salvando un file dai dati della MT5 (ad esempio, un mese in anticipo).
Questo è ciò che faccio per la MT4.
Stanislav Korotky:
ИМХО, все же не хватает более подробной документации. Понятно, что можно заглянуть в код, но тогда вместо разбирания в чужом коде можно и свой написать ;-).
All'interno di mqh premere ALT+M. I nomi dei metodi sembrano avere senso.
In particolare, non è chiaro se Get possa essere richiamato senza aver prima eseguito Set e se sia possibile annullare il filtro (a quanto ho capito, non è possibile).
Set - riempie l'oggetto di eventi. L'accesso a questi ultimi è come l'accesso agli elementi di un array.
Dagli esempi sopra riportati non è chiaro se esista un modo più conveniente per tracciare il verificarsi dell'evento - in particolare, se ho capito bene, è necessario confrontare change_id, non il verificarsi di TimeCurrent, perché l'aggiornamento dei dati non coincide necessariamente con l'inizio dell'evento.
Se parliamo di backtest, non c'è e non può esserci un change_id.
Per quanto riguarda il tempo reale, questa funzionalità sarà aggiunta un po' più avanti nella libreria.
Il rollback del filtro è identico a quello di ogni altra cosa: fare una copia dell'oggetto prima del filtro.
Dal punto di vista architettonico, è possibile incorporare altre fonti di dati sotto forma di parser. A questo scopo esiste anche un campo EVENT::Source, che ora è uguale a un solo valore "MetaTrader5".
Esiste quindi una funzionalità per impilare i calendari. Si suppone che abbia preso i dati da diverse fonti e li abbia poi combinati in un unico posto.
Se parliamo di backtest, non c'è e non può esserci nessun change_id.
Si tratta di una sfumatura discutibile: nella vita reale gli eventi possono cambiare e se il tester (tramite la libreria) non riproduce la storia delle modifiche, l'adeguatezza del test cade. Un argomento simile è già stato toccato qui in alcuni thread: gli indicatori online di un evento sono gli stessi e poi vengono corretti. Se effettuiamo il test utilizzando i valori corretti, non otterremo il quadro che l'esperto ha analizzato "al volo". Oppure ho frainteso la situazione dell'accesso agli aggiornamenti.
Si tratta di una sfumatura discutibile: nella vita reale gli eventi possono cambiare e se il tester (tramite la libreria) non riproduce la storia dei cambiamenti, l'adeguatezza del test diminuisce. Un argomento simile è già stato toccato qui in alcuni thread: gli indicatori online di un evento sono gli stessi e poi vengono corretti. Se effettuiamo il test utilizzando i valori corretti, non otterremo il quadro che l'esperto ha analizzato "al volo". Oppure ho frainteso la situazione dell'accesso agli aggiornamenti.
Il calendario contiene quattro valori per ogni evento:
- Attuale (Actual) - il primo valore ricevuto dopo il rilascio della notizia.
- Previsione - il valore previsto (da chi?) prima del rilascio della notizia.
- Precedente - il valore ricevuto per primo dopo che la stessa notizia del calendario è stata rilasciata la volta precedente. Vale a dire che è uguale all'effettivo per la volta precedente: Precedente[i] = effettivo[i - 1].
- Revised - il valore corretto dell'Actual precedente. L'ora (e il numero di volte) di questo aggiornamento non viene memorizzata nel calendario.
In tutti i calendari HTML (compreso quello standard e in Terminal) la tripla (Attuale, Previsione, Precedente) = (Attuale, Previsione, Rivisto). Pertanto, non è possibile utilizzare il campo Rivisto nella cronologia finché non si verifica il prossimo evento rilevante. Gli altri possono essere utilizzati.
Non ci sono (e non possono esserci) informazioni sul valore di ritardo della ricezione dell'Actual o, più precisamente, sulla disincronizzazione di un particolare server di trading e della fonte delle notizie. Per questo motivo non viene preso in considerazione nel backtest. Questa sfumatura è chiara.
Tenendo conto di quanto sopra, è del tutto legittimo confrontare TimeTradeServer con l'ora dell'evento nel backtest. E utilizzando i valori (Precedente, Previsione,Rivisto) subito prima dell'evento, (Attuale, Previsione,Precedente) - subito dopo.
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso

Calendario:
Calendario - analisi fondamentale sulla storia e in tempo reale.
Author: fxsaber