[Erreur dans la récupération de l'heure du senior TF dans le chronomètre ! - page 15
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
Votre indicateur ne suit pas la mise à jour des données.
De nouvelles barres arrivent du courtier et vous ne les vérifiez pas.
J'ai ajouté quelques lignes pour montrer que lorsque vous vérifiez, tout s'affiche correctement.
C'est une situation de travail - vérifier le nouveau bar.
Tu ne le dis pas ! Qu'est-ce qui te fait croire que je dois suivre les nouveaux bars ? Est-ce que c'est écrit dans la documentation ? Je veux dire que je DOIS obtenir la valeur de la fonction, et ensuite je dois nécessairement la comparer avec la valeur précédente ? Il existe une fonction, la fonction est conçue pour fonctionner avec des délais élevés. La fonction peut renvoyer une erreur si elle n'a pas de données, ou renvoyer une valeur incorrecte (égale à 0 dans ce cas). C'est tout. Les programmeurs ne doivent rien faire pour obtenir une valeur 100% correcte.
Mais regardez ce que j'ai trouvé dans la documentation de SeriesInfoInteger() :
Pour obtenir plus d'informations sur l'erreur, vous devez appeler la fonction GetLastError().
Et vous regardez mon tout premier message. Voyez-vous l'erreur 4066 ? Ensuite, l'erreur 0 et le retour de données incorrectes. Pourquoi la fonction (dans ce cas, SeriesInfoInteger()) ne vérifie-t-elle pas la pertinence avant d'envoyer les données ? Pourquoi ne met-il pas le drapeau d'erreur ? Vous voyez, je préfère attendre un peu plus longtemps pour que les contrôles internes passent plutôt que de chercher des erreurs plus tard.
Mais après cela, on m'a donné beaucoup de conseils, avec lesquels je n'ai jamais obtenu de résultat. Et il s'est avéré que ce n'était même pas à propos de la minuterie.
Ok, lisez l'aide)
SeriesInfoInteger
Renvoie des informations sur l'état des données historiques.
Le mot historique signifie quoi ?
Si l'historique est chargé - il n'y a pas d'erreur.
Pas question ! Et qu'est-ce qui vous fait penser que je devrais nécessairement suivre de nouvelles barres ? Est-ce que c'est écrit dans la documentation ? Je veux dire que je DOIS obtenir la valeur de la fonction, et ensuite je dois nécessairement la comparer avec la précédente ? Il existe une fonction, la fonction est conçue pour fonctionner avec des délais élevés. La fonction peut renvoyer une erreur si elle n'a pas de données, ou renvoyer une valeur incorrecte (égale à 0 dans ce cas). C'est tout. Les programmeurs ne doivent rien faire pour obtenir une valeur 100% correcte.
Mais regardez ce que j'ai trouvé dans la documentation de SeriesInfoInteger() :
Dans mon code voir GetLastError() ? Voici un contrôle. Ce contrôle doit être nécessaire et réel ! Toutes les autres solutions sont des béquilles.Vous n'avez rien à faire).
...le courtier vous envoie des données actualisées - si vous voulez, utilisez-les pour le calcul, sinon - pas de problème, utilisez l'historique existant).
ps. c'est le week-end, le marché est fermé, vous avez des données incorrectes dans votre terminal !
et il n'y a pas d'erreur ! !!)
ok, lisez l'aide)
Que signifie le mot "histoire" ?
Si l'historique est chargé - il n'y a pas d'erreur.
Vous ne devez rien).
...le courtier vous envoie des données actualisées - si vous voulez les utiliser pour calculer, sinon - pas de problème, utilisez l'historique)
Chaque tique qui entre dans le terminal est déjà une histoire. Et je veux obtenir ses valeurs réelles ou son erreur. Si cela vous convient - ok.
Chaque tique qui entre dans le terminal est déjà une histoire. Et je veux recevoir ses valeurs réelles ou son erreur. Si cela vous convient, c'est bien.
Oui, l'historique est ce qui a déjà été téléchargé ou ce qui est en cours de téléchargement dans le passé.
Et ce qui est mis à jour seulement maintenant (après la dernière citation) n'est pas l'histoire, ce sont les nouvelles données brutes.
Vérifiez le temps des bougies, pas le calcul des barres.
C'est ainsi qu'il sera mis à jour correctement (coché).
Taras, voici le résultat de votre code :
Taras, voici le résultat de votre code :
Oui, c'est le premier tic, celui qui produit l'histoire finie, celle qui est disponible.
Après ce tick (s'il y a de nouvelles barres), vient immédiatement le second tick, dans lequel mon code met à jour vos variables et elles montrent les données correctes.
ps. vous pouvez insérer votre propre fonction pour vérifier la nouvelle barre, ce sera la même chose.
Moi-même, je vérifie constamment le nombre de barres, si le nombre a changé de plus de 1, cela signifie que vous devez tout recalculer à nouveau, si le nombre a changé de 1, cela signifie juste une nouvelle barre. Et je ne vérifie que les erreurs les plus critiques, et je ne vois pas cette erreur de retard.
Oui, c'est la première coche, celle qui donne l'historique prêt.
Après ce tick (s'il y a de nouvelles barres), vient immédiatement le second tick, dans lequel mon code met à jour vos variables et elles montrent les données correctes.
Si le nombre a changé de plus de 1, il s'agit d'une nouvelle barre.
Moi-même, je vérifie constamment le nombre de barres, si le nombre a changé de plus de 1, cela signifie que vous devez tout recalculer à nouveau, si le nombre a changé de 1, cela signifie juste une nouvelle barre. Et je ne vérifie que les erreurs les plus critiques, et je ne vois pas cette erreur de retard.
Et voici, d'ailleurs, un autre argument en faveur de la survenue de l'erreur. C'est une ERREUR de calcul dans l'indicateur ! J'ai écrit un conseiller expert :
S'exécute sur le même graphique que l'indicateur. Voyons les résultats :
Ce que nous voyons. Nous voyons que tout va bien. Tout est chargé, et notez qu'il n'y a pas d'erreurs, les données sont immédiatement mises à jour ! La question principale est de savoir pourquoi les données GMT peuvent être obtenues normalement, alors que l'indicateur doit "jouer avec des diamants" ? Les programmes ne devraient-ils pas fonctionner de la même manière ? Pourquoi le même code fonctionne différemment dans un indicateur et dans un Expert Advisor ? Cela ne devrait pas être le cas.
Et voici, d'ailleurs, un autre argument en faveur de la survenue d'une erreur. C'est l'ERREUR dans le calcul de l'indicateur ! J'ai écrit un conseiller expert :
S'exécute sur le même graphique que l'indicateur. Voyons les résultats :
Ce que nous voyons. Nous voyons que tout va bien. Tout est chargé, et notez qu'il n'y a pas d'erreurs, les données sont immédiatement mises à jour ! La question principale est de savoir pourquoi les données GMT peuvent être obtenues normalement, alors que l'indicateur doit "jouer avec des diamants" ? Les programmes ne devraient-ils pas fonctionner de la même manière ? Pourquoi le même code fonctionne différemment dans un indicateur et dans un Expert Advisor ? Cela ne devrait pas être le cas.
Tous les indicateurs sont dans un seul thread, et rien de nouveau ne se produira jusqu'à la fin du flux (en fait, jusqu'au prochain appel d'OpsulCalcuter). L'Expert Advisor est dans son propre thread séparé, donc quand il démarre, il est autorisé à reporter son démarrage pour les mises à jour des données, mettre à jour les données - tout le reste dans le terminal n'est pas affecté. C'est comme ça depuis la naissance et il n'y a aucun moyen de le réparer, car l'environnement metatrader4 a été enterré.
Parce que c'est au terminal de se connecter et de faire quelque chose avec le chargement, la vérification, etc., tous les indicateurs sont dans un thread, et rien de nouveau ne se produit jusqu'à ce que tout dans le thread se termine (en fait, jusqu'au prochain appel de OpCalculate), c'est-à-dire qu'en étant dans ce thread, vous n'obtiendrez rien plus vite que la fin du thread de toute façon. L'Expert Advisor est dans son propre thread séparé, donc quand il démarre, il est autorisé à reporter son démarrage pour les mises à jour des données, mettre à jour les données - tout le reste dans le terminal n'est pas affecté. C'est comme ça depuis la naissance et il n'y a aucun moyen de le réparer, car l'environnement metatrader4 a été enterré.
Je suis conscient du fait que tous les indicateurs d'un même symbole se trouvent dans un seul fil, alors que chaque expert a son propre fil. Mais ce n'est pas le cas. Ce sont les développeurs qui corrigent les erreurs dans leurs créations. Les programmes ne devraient pas fonctionner différemment ! Si les indicateurs ont manqué quelque chose, c'est une erreur et il n'y a pas de problème. Le conseiller expert a en quelque sorte reçu les données correctes sans erreur ! Nous pouvons donc le mettre en œuvre. @Slava, pouvez-vous donner votre avis sur le fait que le comportement manifestement erroné sera corrigé ? Ou, au moins, l'ajout de documentation (qu'avec prev_calculated = 0 aucune donnée correcte des TFs seniors ne peut être obtenue) ?
Oui, je suis conscient que tous les indicateurs d'un même symbole sont dans un seul fil, et qu'un fil différent est attribué à chaque expert. Mais ce n'est pas le cas. Ce sont les développeurs qui corrigent les erreurs dans leurs créations. Les programmes ne devraient pas fonctionner différemment ! Si les indicateurs ont manqué quelque chose, c'est une erreur et il n'y a pas de problème. Le conseiller expert a en quelque sorte reçu les données correctes sans erreur ! Nous pouvons donc le mettre en œuvre. @Slava, pouvez-vous donner votre avis sur le fait que le comportement manifestement erroné sera corrigé ? Ou au moins, est-ce un ajout à la documentation (que nous ne pouvons pas obtenir des données correctes de TF élevé lorsque prev_calculated = 0) ?
La documentation indique que le conseiller expert a jusqu'à 5 secondes avant de commencer à recevoir des données et pendant ce temps, le terminal essaie de recevoir des données pour le conseiller expert. L'indicateur n'a pas cette possibilité et de la même façon il ne devrait pas demander le rafraîchissement de l'historique, ce n'est pas critique pour lui, si c'est critique, alors il doit être calculé dans un Expert Advisor. L'idée principale est que la situation souhaitée n'est pas possible dans la mise en œuvre actuelle. Fondamentalement, les TF sont des minuteries et il y a des périodes où ces multiples minuteries coïncident à un moment donné - il s'agit d'un processus synchrone coïncidant à 100 % (à l'exception de l'heure d'ouverture/de fermeture), car le premier tick de la minute du TF actuel coïncide avec la première minute des cinq minutes, de l'heure, etc. - il s'agit simplement d'écrire la même valeur dans plusieurs variables, et il est logique de définir un ensemble de TF nécessaires et d'obtenir toutes les données nécessaires en une seule fois. Je ne sais pas pourquoi les développeurs l'ont fait et pas l'inverse. Peut-être que cela ne peut pas (ne veut pas) se faire dans le modèle actuel de fonctionnement des terminaux à cause de la division client-serveur, car si nous permettons maintenant aux experts d'utiliser les indicateurs, ils accrocheront le terminal.
Vous pourrez voir en fin de journée, si cela vous intéresse, comment fonctionne l'appel d'indicateur, l'indicateur appelle un autre indicateur, l'expert(_asktfexp) appelle l'indicateur(_asktf_sample) appelle l'indicateur(_asktf). Lorsqu'on appelle un indicateur à partir d'un expert, la minuterie de l'indicateur ne démarrera pas, donc les solutions avec une minuterie dans l'indicateur ne sont que pour les cas où cet indicateur sera seulement suspendu sur le graphique et ne sera pas appelé (ce qui est logique en général).