Symboles personnalisés. Erreurs, bogues, questions, suggestions. - page 12
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
Bug 16.
Auparavant, CustomTicksAdd générait des barres à partir de ticks qui se référaient à la journée en cours. Ce n'est pas non plus le cas aujourd'hui.
Ce bogue semble être lié au bogue n°14.
Le retrait du symbole de l'aperçu du marché est possible pour la raison suivante. Le fait d'appeler consécutivement CustomSymbolCreate - CustomSymbolDelete - CustomSymbolCreate avec le même nom de symbole personnalisé provoquait l'apparition de l'ID du symbole. Par conséquent, lorsque l'on vérifie si un symbole peut être retiré de la vue d'ensemble du marché, le graphique de ce symbole n'a pas été trouvé (l'identifiant est corrompu), et le symbole a été retiré en toute sécurité. Ceci a été corrigé.
Lorsque l'on applique un tick à un graphique, la même chose est possible - la recherche du graphique par l'identifiant du symbole n'a pas donné de résultat.
Bug 15.
Nous exécutons l'indicateur suivant sur le symbole de cet EA (avec ChartSetSymbolPeriod-row supprimé)
Il ne produit que des zéros.
C'est juste.
L'appel à CustomRatesUpdate remet à zéro tous les compteurs de changement et recalcule les indicateurs à partir de zéro.
A juste titre.
Lorsque vous appelez CustomRatesUpdate, tous les compteurs de changement sont remis à zéro et les indicateurs sont recalculés à partir de zéro.
Quelle est la logique qui sous-tend cette solution ? Après tout, il y a des barres inchangées sur la gauche.
Quelle est la logique qui sous-tend cette solution ? Après tout, il y a des barres invariantes sur la gauche.
prev_calculated contient une valeur qui a été renvoyée lors d'un appel OnCalculate précédent.
L'indicateur peut renvoyer n'importe quelle valeur en fonction de sa propre logique. Il est donc inutile de passer en revue tous les indicateurs et de remplacer la valeur de prev_calculated par sa propre valeur calculée en tenant compte de l'horizon temporel. Et il est gourmand en ressources, peut-être même déraisonnablement gourmand en ressources.
Il est beaucoup plus honnête de le mettre à 0, comme au début, lorsque rien n'était encore compté.
prev_calculé contient la valeur qui a été retournée lors du précédent appel à OnCalculate.
L'auteur de l'indicateur peut renvoyer n'importe quelle valeur en fonction de sa propre logique. Il est donc inutile de passer en revue tous les indicateurs et de remplacer la valeur de prev_calculated par sa propre valeur calculée en tenant compte de l'horizon temporel. Et il est gourmand en ressources, peut-être même déraisonnablement gourmand en ressources.
Il est beaucoup plus honnête de le mettre à 0, comme au début, lorsque rien n'était encore compté.
Que faire alors lorsque les indicateurs d'un symbole personnalisé sont complètement recalculés à cause de cette valeur nulle après chaque retournement de tick ?
Les indicateurs sont spécialement écrits pour ne pas ralentir le Terminal, et ici c'est le contraire qui se produit.
Mais qu'en est-il lorsque, sur un symbole personnalisé, après chaque retournement de tic, les indicateurs sont complètement recalculés à cause de cette valeur zéro ?
Cela ne devrait pas être le cas. Vérifiez
Ça ne devrait pas être comme ça. Vérifiez
Permettez-moi de préciser qu'il ne s'agit pas seulement de CustomTicksAdd, mais aussi de RatesUpdate, qui est un tic-tac du passé. En fait, même le TicksAdd fonctionnel n'a pas formé les barres antérieures au jour courant. Nous devons les former nous-mêmes. Et nous obtenons zéro prev_calculé à cause de cela.
Pour clarifier, il ne s'agit pas seulement de CustomTicksAdd, mais aussi de RatesUpdate, qui est un tick-through du passé. En fait, même le TicksAdd fonctionnel n'a pas formé les barres antérieures au jour courant. Nous devons les former nous-mêmes. Et nous obtenons zéro prev_calculé à cause de cela.
De toute façon, lors du remplacement, du rafraîchissement ou de la suppression des barres, tous les indicateurs seront recalculés à partir de zéro. C'est hors de question.
L'ajout de ticks devrait fonctionner comme d'habitude, c'est-à-dire que les ticks sont des ticks frais, actuels, mais pas les ticks d'hier/de la veille.
J'ai exécuté votre conseiller expert à partir de la description du bug 11, puis j'ai exécuté l'indicateur avec une impression sur chaque OnCalculate.
Voici les journaux.
Cela signifie que tout fonctionne correctement dans une situation normale (les tics sont aujourd'hui, comme ils devraient toujours l'être). Les tics sont ajoutés, et l'indicateur est considéré avec parcimonie
Dans tous les cas, lors du remplacement, de la mise à jour, de la suppression des barres, tous les indicateurs seront recalculés à partir de zéro. C'est hors de question.
L'ajout de ticks devrait fonctionner comme d'habitude, c'est-à-dire que les ticks sont frais, ceux d'aujourd'hui, et non ceux d'hier - d'avant-hier.
Exécuter votre Expert Advisor à partir de la description du bug 11, puis exécuter l'indicateur avec l'impression sur chaque OnCalculate
Voici les journaux.
Cela signifie que tout fonctionne correctement dans une situation normale (les tics sont d'actualité, comme ils devraient toujours l'être). Les tics s'ajoutent, et l'indicateur est considéré avec parcimonie
Cette affirmation est-elle correcte ?
De plus, s'il s'agit de 00:00:01, nous ne pouvons pas utiliser CustomTicksAdd pour remodeler une barre qui ne date que de deux secondes.
Cette affirmation est-elle correcte ?
Pour le testeur, le tick d'avant-hier est frais, le tick d'aujourd'hui celui d'avant-hier.
Je comprends votre point de vue. Votre exercice avec les tics personnalisés d'il y a six mois est d'une nature nettement expérimentale. Votre situation n'est pas normale (dans le sens d'une pratique normale)