L'erreur 4066 est un problème typique pour les utilisateurs de MTF, le terminal n'a pas pompé les données des autres TFs, il faut vérifier l'intégrité des données des autres TFs.
Regardez de plus près le code et ce que j'ai écrit avant de donner des conseils.
Le code comporte une vérification des erreurs et une vérification des données vides. Et lorsqu'une fonction renvoie des données incorrectes sans erreur, il s'agit d'une erreur !
Regardez de plus près le code et ce que j'ai écrit avant de donner des conseils.
Le code comporte une vérification des erreurs et une vérification des données vides. Et lorsqu'une fonction renvoie des données incorrectes sans erreur, il s'agit d'une erreur !
Peut-être ai-je manqué quelque chose et montrez-moi où vous vérifiez l'intégrité de l'historique, par exemple, dans la procédureCheckCurrentHourOpenTime()
Qu'entendez-vous par intégrité de l'histoire ?
Je parle du fait qu'il y a une vérification des erreurs lors de la récupération des valeurs de l'historique. Il y a un contrôle dans chaque fonction. C'est ici :
//--- Проверяем, получено ли время открытия часового бара if(tempHourOpenTime==0 || err!=0) // Если время бара не получено return(false); // Возвращаем ложь
C'est-à-dire que si la valeur zéro ou une erreur est reçue - le temps n'est pas écrit dans la variable globale. Vous pensez que ce n'est pas suffisant ?
Le fait est que la fonction SeriesInfoInteger() renvoie d'abord une erreur, mais qu'à l'exécution suivante, elle renvoie NON ! Et il ne renvoie pas non plus la bonne valeur !SeriesInfoInteger() renvoie uniquement les informations pour une certaine requête, dans ce cas nous demandons de renvoyer le dernier temps d'ouverture de barre connu dans l'historique par symbole et période. Il n'y a pas d'erreur ici, ce qui était le plus récent à ce moment-là est ce qu'il a retourné. Je vais vous montrer comment vérifier l'intégrité de l'historique.
SeriesInfoInteger() renvoie uniquement les informations pour une certaine requête, dans ce cas nous demandons de renvoyer le dernier temps d'ouverture de barre connu dans l'historique par symbole et période. Il n'y a pas d'erreur ici, ce qui était le plus récent à ce moment-là est ce qu'il a retourné. Je vais me rendre sur le PC et vous montrer comment vérifier l'intégrité de l'historique.
Comment ça, il n'y a pas d'erreur ici ! ? Alors pourquoi donne-t-il de "faux" codes d'erreur ? Il dit que l'histoire est correcte alors qu'elle ne l'est pas...
Comment ça, il n'y a pas d'erreur ici ! ? Alors pourquoi donne-t-il de 'faux' codes d'erreur ? Il dit que l'histoire est correcte alors qu'elle ne l'est pas...
Encore une fois, cette fonction ne vérifie pas l'intégrité de l'historique ! Il renvoie les informations qu'il a pu y trouver. Dans ce cas particulier, il a trouvé la barre d'heure qui avait été demandée lors de la fermeture du terminal. Le reste de l'historique n'a pas encore été chargé.
Pour vérifier si l'historique d'un TF donné est complètement paginé, il suffit d'utiliser une fonction :
bool IsTFDataReady(ENUM_TIMEFRAMES eTF) { ResetLastError(); iTime(NULL, eTF, 1); return GetLastError() == ERR_NO_ERROR; }
Si la fonction renvoie false, les données pour le TF demandé sont incomplètes. Sinon, il est complet.
Encore une fois, cette fonction ne vérifie pas l'intégrité de l'histoire ! Il renvoie les informations qu'il a pu y trouver. Dans ce cas, il a trouvé la barre d'heure qui a été demandée lors de l'arrêt du terminal. Le reste de l'historique n'a pas encore été chargé.
Encore une fois. Ce n'est mentionné nulle part. C'est la première chose. Deuxièmement, pourquoi est-il trompeur en affichant d'abord le code d'erreur 4066 et ensuite non ?
Pour vérifier si l'historique d'un TF donné est complètement paginé, il suffit d'utiliser une fonction :
Si la fonction renvoie false, les données pour le TF demandé sont incomplètes. Sinon, il est complet.
L'avez-vous vérifié dans le minuteur ? Vous voyez que j'ai commenté des lignes ? J'ai vérifié cette fonction, elle n'a montré aucune erreur du tout et a également montré des données incorrectes. Je vais vérifier à nouveau.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Objectif : Au démarrage de l'indicateur, obtenir les données actuelles dans le timer : l'heure d'ouverture de la barre hebdomadaire, quotidienne et horaire. Ensuite, écrivez-les dans des variables globales pour une utilisation ultérieure. La période actuelle est М1.
Mise en œuvre : Nous obtenons les heures des barres en utilisant la fonction SeriesInfoInteger().
Résultat : si le terminal a fonctionné pendant plusieurs heures, par exemple s'il était éteint pour la nuit, nous obtenons un tel résultat lors de son premier démarrage (un jour) :
Comme vous pouvez le constater, l'heure de récupération des données est 2018.09.21 11:11, et pour cette heure, nous obtenons l'heure d'ouverture du jour = 2018.09.20 (alors qu'elle devrait être 2018.09.21) et l'heure d'ouverture de l'heure = 2018.09.20 16:00 (alors qu'elle devrait être 2018.09.21 11:00). Et l'heure renvoyée par le terminal n'est rien d'autre que les données au moment de sa dernière fermeture. C'est-à-dire que les données sont mises en cache et renvoyées indépendamment du fait que le terminal a été fermé. Et je comprendrais que l'erreur #4066 soit retournée à chaque fois (données historiques demandées en état de mise à jour) jusqu'à ce que les données soient mises à jour, mais non, ce sont les données ERROR qui sont retournées ! Cette erreur n'est renvoyée qu'une seule fois et vous pouvez ensuite vous en accommoder. Il y a une erreur manifeste de mise en cache. Je demande aux développeurs(@Slava) d'y prêter attention !
Je répète. Des données erronées apparaîtront si elles sont demandées dans le timer !
Version du terminal : x64, 1090.