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
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.