fxsaber: Confronté à un bug lorsque CopyTicksRange renvoie correctement tous les ticks demandés, mais avec LastError == ERR_HISTORY_TIMEOUT(4403).
Ce n'est pas un bug, c'est une fonctionnalité. C'est la même chose avec CopyTicks, parfois. Je n'ai pas encore trouvé comment utiliser ce "truc".
dans la description de la fonction CopyTicksRange :
ERR_HISTORY_TIMEOUT – время ожидание синхронизации тиков вышло, функция отдала всё что было.
Bien entendu, j'aimerais que les développeurs expliquent ce que signifie cette erreur lorsqu'un tick est reçu avec la fonction CopyTicks. Comment gérer cette erreur. ps : je l'appelle dans un indicateur
ZS Dans la remorque est personnalisé. Créer un symbole à partir de json, importer les ticks, exécuter le script sur le graphique de ce symbole. Veuillez indiquer si elle s'est reproduite ou non.
ZY La remorque est personnalisée. Créer un symbole à partir de json, importer les ticks, exécuter le script sur le graphique de ce symbole. Veuillez écrire si cela s'est reproduit ou non.
Merci encore.
Oui, en 2380, le problème a été accidentellement introduit, puis il a été rapidement corrigé. Mais il a réussi à atteindre la version 2380.
Malheureusement, depuis lors, les nouvelles constructions où tous les correctifs sur MetaQuotes-Demo n'était pas encore.
Vous pouvez soit revenir à une version précédente, soit attendre la prochaine version de MetaQuotes-Demo.
1.1. Avec les dates données, la sortie est similaire à la vraie : 2000 0 2000 0.
1.2. Lorsque les dates sont modifiées en 07.04.2020-08.04.2020, la sortie devient étrange : -1 4004 1 0.
Tout d'abord, pourquoi l'erreur apparaît-elle dans le premier cas ? Deuxièmement, pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.
2. Compte de couverture.
2.1. Avec les dates données, la sortie devient étrange : 2000 0 1 0.
Pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.
2.2. Lorsque les dates passent au 07.04.2020-08.04.2020, la sortie cesse d'être étrange, mais reste la même : 2000 0 1 0.
D'où les questions suivantes : pourquoi les CopyTicks à paramètres fixes dépendent-ils non seulement des dates de test, mais aussi du type de compte ? Ou je ne comprends pas quelque chose et je fais quelque chose de mal ?
Cela rend le travail très difficile, veuillez corriger si possible. Avez-vous réussi à le reproduire ? Vous avez besoin de quelque chose d'autre de ma part pour la reproduction ? Merci.
D'où les questions suivantes : pourquoi CopyTicks avec des paramètres fixes dépend-il non seulement des dates de test, mais aussi du type de compte ? Ou est-ce que je comprends mal quelque chose et fais quelque chose de mal ?
Dépendance vis-à-vis du type de compte - vous pouvez imaginer les raisons. Je ne dirais pas que c'est correct. Les symboles d'échange avec la dernière histoire - les développeurs doivent bien penser une fois là, ce qu'il faut en faire sur la haie, etc.
Je n'utilise pas moi-même les CopyTicks dans Tester. Les premières 24 heures ne sont pas importantes. Si vous avez vraiment besoin de signaux de négociation clairs, ne négociez pas le premier jour.
MT5 dernière version, build 2361. Créez un symbole à partir de json, importez les ticks, exécutez l'EA sur un graphique de ce symbole.
EA
Paramètres
1. Compte de compensation.
1.1. Avec les dates données, la sortie est similaire à la vraie : 2000 0 2000 0.
1.2. Lorsque les dates sont modifiées en 07.04.2020-08.04.2020, la sortie devient étrange : -1 4004 1 0.
Tout d'abord, pourquoi l'erreur apparaît-elle dans le premier cas ? Deuxièmement, pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.
2. Compte de couverture.
2.1. Avec les dates données, la sortie devient étrange : 2000 0 1 0.
Pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.
2.2. Lorsque les dates passent au 07.04.2020-08.04.2020, la sortie cesse d'être étrange, mais reste la même : 2000 0 1 0.
D'où les questions suivantes : pourquoi les CopyTicks à paramètres fixes dépendent-ils non seulement des dates de test, mais aussi du type de compte ? Ou je ne comprends pas quelque chose et je fais quelque chose de mal ?
Cela rend le travail très difficile, veuillez corriger si possible. Avez-vous réussi à le reproduire ? Vous avez besoin de quelque chose d'autre de ma part pour la reproduction ? Merci.
La toute première course. En regardant les logs du testeur.
2020.04.2110:53:10.573 Core 01 AUDNZD.RannForex: symbol to be synchronized
2020.04.2110:53:10.573 Core 01 AUDNZD.RannForex: symbol synchronized, 3720 bytes of symbol info received
2020.04.2110:53:10.573 Core 01 AUDNZD.RannForex: load 23 Kb of history data to synchronize in0:00:00.0092020.04.2110:53:10.573 Core 01 AUDNZD.RannForex: history synchronized from2020.04.06 to 2020.04.082020.04.2110:53:10.573 Core 01 AUDNZD.RannForex: ticks synchronization started
2020.04.2110:53:10.573 Core 01 AUDNZD.RannForex: load 567 Kb of tick data to synchronize in0:00:00.0312020.04.2110:53:10.573 Core 01 AUDNZD.RannForex: history ticks synchronized from2020.04.08 to 2020.04.082020.04.2110:53:10.573 Core 01 AUDNZD.RannForex,M1: history cache allocated for3897 bars and contains 2868 bars from2020.04.0600:05 to 2020.04.0723:592020.04.2110:53:10.573 Core 01 AUDNZD.RannForex,M1: history begins from2020.04.0600:052020.04.2110:53:10.573 Core 01 AUDNZD.RannForex,M1 (MetaQuotes-Demo): generating based on real ticks
2020.04.2110:53:10.573 Core 01 AUDNZD.RannForex,M1: testing of Experts\test.ex5 from2020.04.0800:00 to 2020.04.0900:00 started
2020.04.2110:53:10.573 Core 01 AUDNZD.RannForex : real ticks begin from2020.04.0800:00:002020.04.2110:53:10.573 Core 012020.04.0800:01:11 -12020.04.2110:53:10.573 Core 012020.04.0800:01:1140042020.04.2110:53:10.573 Core 012020.04.0800:01:1112020.04.2110:53:10.573 Core 012020.04.0800:01:1102020.04.2110:53:10.573 Core 012020.04.0800:01:11 ExpertRemove() function called
2020.04.2110:53:10.573 Core 01 removed itself within OnTick
Le testeur a synchronisé les tics pour un seul jour, le 8 avril. C'est-à-dire qu'il n'y a pas de tiques avant le 8 avril.
Au début, nous avons obtenu l'erreur 4004 (pas assez de mémoire pour les ticks demandés). C'est un message invalide, nous allons l'examiner. Il semble que ce soit parce que la demande avec les paramètres par défaut se trouve à la limite des ticks existants.
La requête suivante vous a donné, à juste titre, 1 coche. Parce que depuis 2020.04.06 00:00:00 jusqu'au testeur actuel, lorsque le premier tick est arrivé, il n'y a qu'un seul tick existant.
et nous voyons, qu'à partir de la deuxième tique, les tiques ont commencé à être ramassées. Dans les deux cas, il s'agit de 2 ticks.
2020.04.2111:14:13.256 Core 01 AUDNZD.RannForex : real ticks begin from 2020.04.0800:00:002020.04.2111:14:13.256 Core 012020.04.0800:01:11 -12020.04.2111:14:13.256 Core 012020.04.0800:01:1922020.04.2111:14:13.256 Core 012020.04.0800:01:1902020.04.2111:14:13.256 Core 012020.04.0800:01:1922020.04.2111:14:13.256 Core 012020.04.0800:01:1902020.04.2111:14:13.256 Core 012020.04.0800:01:19ExpertRemove() function called
En d'autres termes, l'hypothèse relative à l'erreur de demande sur la limite du tick s'est avérée correcte.
Changeons la date de début au 7 avril.
2020.04.2111:18:17.775 Core 01 AUDNZD.RannForex: history ticks synchronized from2020.04.07 to 2020.04.082020.04.2111:18:17.775 Core 01 AUDNZD.RannForex,M1: history cache allocated for3486 bars and contains 1429 bars from2020.04.0600:05 to 2020.04.0623:592020.04.2111:18:17.775 Core 01 AUDNZD.RannForex,M1: history begins from2020.04.0600:052020.04.2111:18:17.775 Core 01 AUDNZD.RannForex,M1 (MetaQuotes-Demo): generating based on real ticks
2020.04.2111:18:17.775 Core 01 AUDNZD.RannForex,M1: testing of Experts\test.ex5 from2020.04.0700:00 to 2020.04.0900:00 started
2020.04.2111:18:17.775 Core 01 AUDNZD.RannForex : real ticks begin from2020.04.0700:00:002020.04.2111:18:17.775 Core 012020.04.0700:01:28 -12020.04.2111:18:17.775 Core 012020.04.0700:01:2840042020.04.2111:18:17.775 Core 012020.04.0700:01:2812020.04.2111:18:17.775 Core 012020.04.0700:01:2802020.04.2111:18:17.775 Core 012020.04.0700:01:28 ExpertRemove() function called
2020.04.2111:18:17.775 Core 01 removed itself within OnTick
Tout est identique, à l'exception du fait que les ticks sont synchronisés pour 2 jours déjà - la base de données du testeur contient les ticks des 7 et 8 avril.
Nous avons reporté la date de début au 8 avril. Et nous voyons le résultat attendu
2020.04.2111:20:51.257 Core 01 AUDNZD.RannForex: load 47 bytes of history data to synchronize in0:00:00.0002020.04.2111:20:51.257 Core 01 AUDNZD.RannForex: history synchronized from2020.04.06 to 2020.04.082020.04.2111:20:51.257 Core 01 AUDNZD.RannForex: ticks synchronization started
2020.04.2111:20:51.257 Core 01 AUDNZD.RannForex: load 54 bytes of tick data to synchronize in0:00:00.0002020.04.2111:20:51.257 Core 01 AUDNZD.RannForex: history ticks synchronized from2020.04.07 to 2020.04.082020.04.2111:20:51.257 Core 01 AUDNZD.RannForex,M1: history cache allocated for3897 bars and contains 2868 bars from2020.04.0600:05 to 2020.04.0723:592020.04.2111:20:51.257 Core 01 AUDNZD.RannForex,M1: history begins from2020.04.0600:052020.04.2111:20:51.257 Core 01 AUDNZD.RannForex,M1 (MetaQuotes-Demo): generating based on real ticks
2020.04.2111:20:51.257 Core 01 AUDNZD.RannForex,M1: testing of Experts\test.ex5 from2020.04.0800:00 to 2020.04.0900:00 started
2020.04.2111:20:51.257 Core 01 AUDNZD.RannForex : real ticks begin from2020.04.0700:00:002020.04.2111:20:51.257 Core 012020.04.0800:01:1120002020.04.2111:20:51.257 Core 012020.04.0800:01:1102020.04.2111:20:51.257 Core 012020.04.0800:01:1120002020.04.2111:20:51.257 Core 012020.04.0800:01:1102020.04.2111:20:51.257 Core 012020.04.0800:01:11 ExpertRemove() function called
2020.04.2111:20:51.257 Core 01 removed itself within OnTick
Parce qu'il y a plus de tics dans le testeur que dans la toute première exécution. Et cela n'a rien à voir avec la couverture et la compensation.
Confronté à un bug lorsque CopyTicksRange renvoie correctement tous les ticks demandés, mais avec LastError == ERR_HISTORY_TIMEOUT(4403).
Ce n'est pas un bug, c'est une fonctionnalité. C'est la même chose avec CopyTicks, parfois. Je n'ai pas encore trouvé comment utiliser ce "truc".
dans la description de la fonction CopyTicksRange :
ERR_HISTORY_TIMEOUT – время ожидание синхронизации тиков вышло, функция отдала всё что было.Bien entendu, j'aimerais que les développeurs expliquent ce que signifie cette erreur lorsqu'un tick est reçu avec la fonction CopyTicks. Comment gérer cette erreur. ps : je l'appelle dans un indicateur
Veuillez indiquer quelles données doivent être fournies pour résoudre ce problème dans les plus brefs délais.
Tiki n'est pas copié, ce qui donne une erreur.
Constant
Valeur
Description
ERR_HISTOIRE_SMALL_BUFFER
4407
Le tableau de réception est trop petit pour contenir toutes les données demandées.
Il est impossible de travailler correctement avec de telles surprises !
A travers le GUI (CTRL+U) les ticks sont pris sans aucun problème.
Nom de recherche: Oshibka 007.Veuillez indiquer quelles données doivent être fournies pour résoudre ce problème dans les plus brefs délais.
Tiki n'est pas copié, ce qui donne une erreur.
Constant
Valeur
Description
ERR_HISTOIRE_SMALL_BUFFER
4407
Le tableau de réception est trop petit pour contenir toutes les données demandées.
Testé localement de diverses manières - jusqu'à présent, pas de lecture. Besoin de plus de détails :
1. Quelle version du terminal ?
2. Avec quel serveur travaillez-vous ?
3. sur quel personnage le script est-il appelé ?
4. Si l'appel n'est pas effectué avec COPY_TICKS_INFO mais avec COPY_TICKS_ALL, l'erreur ERR_HISTORY_SMALL_BUFFER est-elle également activée ?
Merci !
Testé localement de différentes manières - jusqu'à présent, pas de lecture. Besoin de détails :
1. Quelle version du terminal ?
2. Avec quel serveur travaillez-vous ?
3. sur quel personnage le script est-il appelé ?
4. Si vous ne l'appelez pas avec COPY_TICKS_INFO mais avec COPY_TICKS_ALL, l'erreur ERR_HISTORY_SMALL_BUFFER sera-t-elle également levée ?
Merci !
ZS Dans la remorque est personnalisé. Créer un symbole à partir de json, importer les ticks, exécuter le script sur le graphique de ce symbole. Veuillez indiquer si elle s'est reproduite ou non.
Veuillez écrire si elle a joué ou non.
Oui, c'est passé sur 2380.
Merci beaucoup ! Je fais le tri.
ZY La remorque est personnalisée. Créer un symbole à partir de json, importer les ticks, exécuter le script sur le graphique de ce symbole. Veuillez écrire si cela s'est reproduit ou non.
Merci encore.
Oui, en 2380, le problème a été accidentellement introduit, puis il a été rapidement corrigé. Mais il a réussi à atteindre la version 2380.
Malheureusement, depuis lors, les nouvelles constructions où tous les correctifs sur MetaQuotes-Demo n'était pas encore.
Vous pouvez soit revenir à une version précédente, soit attendre la prochaine version de MetaQuotes-Demo.Vous pouvez soit revenir à une version précédente, soit attendre la prochaine version de MetaQuotes-Demo.
Merci, pour l'instant la construction précédente est réelle. Le 2380 a fait beaucoup...
MT5 dernière version, build 2361. Créez un symbole à partir de json, importez les ticks, exécutez l'EA sur un graphique de ce symbole.
EA
Paramètres
1. Compte de compensation.
1.1. Avec les dates données, la sortie est similaire à la vraie : 2000 0 2000 0.
1.2. Lorsque les dates sont modifiées en 07.04.2020-08.04.2020, la sortie devient étrange : -1 4004 1 0.
Tout d'abord, pourquoi l'erreur apparaît-elle dans le premier cas ? Deuxièmement, pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.
2. Compte de couverture.
2.1. Avec les dates données, la sortie devient étrange : 2000 0 1 0.
Pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.
2.2. Lorsque les dates passent au 07.04.2020-08.04.2020, la sortie cesse d'être étrange, mais reste la même : 2000 0 1 0.
D'où les questions suivantes : pourquoi les CopyTicks à paramètres fixes dépendent-ils non seulement des dates de test, mais aussi du type de compte ? Ou je ne comprends pas quelque chose et je fais quelque chose de mal ?
Cela rend le travail très difficile, veuillez corriger si possible. Avez-vous réussi à le reproduire ? Vous avez besoin de quelque chose d'autre de ma part pour la reproduction ? Merci.
D'où les questions suivantes : pourquoi CopyTicks avec des paramètres fixes dépend-il non seulement des dates de test, mais aussi du type de compte ? Ou est-ce que je comprends mal quelque chose et fais quelque chose de mal ?
Dépendance vis-à-vis du type de compte - vous pouvez imaginer les raisons. Je ne dirais pas que c'est correct. Les symboles d'échange avec la dernière histoire - les développeurs doivent bien penser une fois là, ce qu'il faut en faire sur la haie, etc.
Je n'utilise pas moi-même les CopyTicks dans Tester. Les premières 24 heures ne sont pas importantes. Si vous avez vraiment besoin de signaux de négociation clairs, ne négociez pas le premier jour.
MT5 dernière version, build 2361. Créez un symbole à partir de json, importez les ticks, exécutez l'EA sur un graphique de ce symbole.
EA
Paramètres
1. Compte de compensation.
1.1. Avec les dates données, la sortie est similaire à la vraie : 2000 0 2000 0.
1.2. Lorsque les dates sont modifiées en 07.04.2020-08.04.2020, la sortie devient étrange : -1 4004 1 0.
Tout d'abord, pourquoi l'erreur apparaît-elle dans le premier cas ? Deuxièmement, pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.
2. Compte de couverture.
2.1. Avec les dates données, la sortie devient étrange : 2000 0 1 0.
Pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.
2.2. Lorsque les dates passent au 07.04.2020-08.04.2020, la sortie cesse d'être étrange, mais reste la même : 2000 0 1 0.
D'où les questions suivantes : pourquoi les CopyTicks à paramètres fixes dépendent-ils non seulement des dates de test, mais aussi du type de compte ? Ou je ne comprends pas quelque chose et je fais quelque chose de mal ?
Cela rend le travail très difficile, veuillez corriger si possible. Avez-vous réussi à le reproduire ? Vous avez besoin de quelque chose d'autre de ma part pour la reproduction ? Merci.
La toute première course. En regardant les logs du testeur.
Le testeur a synchronisé les tics pour un seul jour, le 8 avril. C'est-à-dire qu'il n'y a pas de tiques avant le 8 avril.
Au début, nous avons obtenu l'erreur 4004 (pas assez de mémoire pour les ticks demandés). C'est un message invalide, nous allons l'examiner. Il semble que ce soit parce que la demande avec les paramètres par défaut se trouve à la limite des ticks existants.
La requête suivante vous a donné, à juste titre, 1 coche. Parce que depuis 2020.04.06 00:00:00 jusqu'au testeur actuel, lorsque le premier tick est arrivé, il n'y a qu'un seul tick existant.
Ajustons un peu l'EA
et nous voyons, qu'à partir de la deuxième tique, les tiques ont commencé à être ramassées. Dans les deux cas, il s'agit de 2 ticks.
En d'autres termes, l'hypothèse relative à l'erreur de demande sur la limite du tick s'est avérée correcte.
Changeons la date de début au 7 avril.
Tout est identique, à l'exception du fait que les ticks sont synchronisés pour 2 jours déjà - la base de données du testeur contient les ticks des 7 et 8 avril.
Nous avons reporté la date de début au 8 avril. Et nous voyons le résultat attendu
Parce qu'il y a plus de tics dans le testeur que dans la toute première exécution. Et cela n'a rien à voir avec la couverture et la compensation.