Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Encore une fois. Ça ne le dit nulle part. C'est la première chose. Deuxièmement, pourquoi est-il alors trompeur en montrant d'abord un code d'erreur 4066 et ensuite non ?
Les données sont pompées par lots, puis traitées par le terminal, et comme vous travaillez sur une minuterie, vous êtes en pause. Je ne le vois nulle part explicitement, mais de nombreux programmeurs qui écrivent des applications MTF le savent généralement et je vous en ai déjà parlé.
https://docs.mql4.com/ru/series/timeseries_access l'a lu attentivement.
Eh bien, vous nous avez déjà donné ci-dessus une variante de la vérification de l'accessibilité de l'historique. Il n'est pas parfait mais il est simple et évident.
Si cette variante ne fonctionne pas, vérifiez comme suit.
Les données sont pompées par portions, puis traitées par le terminal, et comme vous êtes sur une minuterie, vous êtes mis en pause. Oui, ce n'est mentionné explicitement nulle part, mais de nombreux programmeurs qui écrivent des applications MTF le savent généralement et je vous l'ai dit tout de suite.
https://docs.mql4.com/ru/series/timeseries_access l'a lu attentivement.
Eh bien, ci-dessus vous nous avez déjà donné une variante de la vérification de l'accessibilité de l'historique. Il n'est pas parfait mais il est simple et évident.
Pour ce qui est d'entrer "dans une pause", où sont les preuves ?
Je l'ai lu attentivement (et je l'ai déjà lu auparavant). Je suis conscient que les données (surtout les anciens TF) ne sont pas toujours immédiatement disponibles. Pas de problème. Mais pourquoi alors la fonction SeriesInfoInteger() ne renvoie-t-elle aucune erreur ? Voici la question !
En supposant que la demande tombe sur une pause/swap/mise à jour/rupture, etc., elle renvoie le code d'erreur != 0. Et il n'y aura aucun problème !
Et ci-dessus, vous avez déjà donné la possibilité de vérifier l'accessibilité de l'histoire. Ce n'est pas parfait, mais c'est simple et direct.
Réponse ci-dessus à @Ihor Herasko sur ce point.
Déjà répondu à @Ihor Herasko ci-dessus sur ce point.
J'ai donné ma version du test ci-dessus. Pourquoi cette question aux développeurs mais ce point est connu depuis longtemps !
Je vais certainement essayer votre version du test et rapporter les résultats.
Je vais certainement essayer votre version du test et vous faire part des résultats.
D'abord une réponse de @Ihor Herasko. Code pour la lecture :
Résultat :
D'après les entrées du journal. Le terminal a été éteint à 14h25. Suivant, allumé à 14h30. Nous vérifions l'heure de la barre M15. Nous avons commencé par le TF M1. L'indicateur (code ci-dessus) indiquait l'heure d'ouverture réelle à 12:15 (heure du terminal, décalée de 2 heures par rapport à mon heure locale). Le résultat aurait dû être 12:30 ! Conclusion - l'erreur est présente. Et cette méthode suggérée par @Ihor Herasko ne fonctionne pas.
N'oubliez pas de faire un rapport ! Ça marche pour moi ! Mais il peut y avoir toutes sortes d'embûches ; si cela ne fonctionne pas, nous réfléchirons à ce que nous pouvons faire d'autre.
Je vais terminer. Code :
Résultat :
J'ai éteint le terminal à 14h48, je l'ai rallumé à 15h01. J'aurais dû avoir l'heure à 13 heures. J'ai eu 12:45. D'autres questions ?
J'ai changé le TF de M1 à M5 et j'ai obtenu un résultat correct :
Je crois que j'ai trouvé ! L'indicateur est-il mis en route immédiatement avec le terminal ? Si c'est le cas, avant de vérifier l'attente d'une connexion au serveur IsConnected() vous avez une minuterie très rapide ; elle n'a pas le temps de se synchroniser !
Ou faites ceci
Mais vous devez tenir compte de la différence entre l'heure du serveur et l'heure locale. Écrivez-nous avec les résultats !