
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ancora una volta. Non c'è scritto da nessuna parte. Questo è prima di tutto. In secondo luogo, perché poi è fuorviante mostrando prima un codice di errore 4066 e poi no?
I dati vengono pompati in batch e poi elaborati dal terminale, e dato che stai lavorando su un timer, sei in pausa. Non lo vedo esplicitamente da nessuna parte, ma molti programmatori che scrivono applicazioni MTF di solito lo sanno e ve ne ho parlato subito.
https://docs.mql4.com/ru/series/timeseries_access leggere attentamente.
Bene, sopra ci hai già dato una variante di controllo dell'accessibilità della storia. Non è perfetto, ma è semplice e ovvio.
Se questa variante non funziona, controllate come segue.
I dati vengono pompati in porzioni e poi elaborati dal terminale, e dato che sei su un timer, vieni messo in pausa. Sì, non è esplicitamente menzionato da nessuna parte, ma molti programmatori che scrivono applicazioni MTF di solito lo sanno e ve ne ho parlato subito.
https://docs.mql4.com/ru/series/timeseries_access leggere attentamente.
Bene, sopra ci hai già dato una variante di controllo dell'accessibilità della storia. Non è perfetto, ma è semplice e ovvio.
Riguardo all'entrare "in una pausa", dove sono le prove?
L'ho letto attentamente (e l'ho letto prima). Sono consapevole del fatto che i dati (specialmente i TF più vecchi) non sono sempre immediatamente disponibili. Nessun problema. Ma perché allora la funzione SeriesInfoInteger() non restituisce alcun errore? Ecco la domanda!
Supponendo che la richiesta cada su qualche pausa/swap/aggiornamento/interruzione ecc., allora lasciamo che restituisca il codice di errore != 0. E non ci saranno problemi!
E sopra avete già dato la possibilità di controllare l'accessibilità della storia. Non è perfetto, ma è semplice e diretto.
Ha risposto sopra @Ihor Herasko su questo punto.
Ha già risposto @Ihor Herasko sopra su questo punto.
Ho dato la mia versione del test qui sopra. Perché questa domanda agli sviluppatori, ma questo punto è noto da molto tempo!
Proverò sicuramente la tua versione del test e riferirò i risultati.
Proverò sicuramente la tua versione del test e ti riferirò i risultati.
Prima una risposta da @Ihor Herasko. Codice per la riproduzione:
Risultato:
Secondo le voci di registro. Il terminale è stato spento alle 14:25. Poi, acceso alle 14:30. Controlliamo l'ora della barra M15. Abbiamo iniziato con TF M1. L'indicatore (codice sopra) ha mostrato l'orario effettivo di apertura alle 12:15 (orario del terminale, in ritardo rispetto al mio orario locale di 2 ore). Il risultato avrebbe dovuto essere 12:30! Conclusione: l'errore è presente. E questo metodo suggerito da @Ihor Herasko non funziona.
Assicurati di fare rapporto! Per me funziona! Ma ci possono essere tutti i tipi di insidie, se non funziona penseremo a cos'altro possiamo fare.
Io chiudo. Codice:
Risultato:
Ho spento il terminale alle 14:48 e l'ho riacceso alle 15:01. Avrebbe dovuto prendere l'ora alle 13:00. Ho le 12:45. Ci sono altre domande?
Ho cambiato TF da M1 a M5 e ho ottenuto il risultato corretto:
Penso di avercela fatta! L'indicatore viene avviato immediatamente con il terminale? Se è così, prima di controllare aspetta una connessione al server IsConnected() hai un timer molto veloce che non ha il tempo di sincronizzarsi!
Oppure fai così
Ma devi tenere conto della differenza tra l'ora del server e l'ora locale. Rispondete con i risultati!