Erreurs, bugs, questions - page 1047
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
Vous devez au moins définir le nombre maximum de barres dans la fenêtre *nécessite un redémarrage du terminal
c'est beaucoup de code avec lequel travailler...
Serveur de démonstration MQ.
Dans les paramètres - barres max. par fenêtre = 100000
Oui, c'est vrai, j'ai essayé, j'ai eu ce "oops" - un pur bug en général, pour le servicedesk.
Donc (d'après ce que j'ai compris) l'indicateur innocent et sans méfiance est appelé avec rates_performance=100000, mais la demande CopyRates(,,100000,) conduit à un pop (array out of range in ...) - le terminal n'a déjà que 50000 de disponible.Je me suis aussi souvenu.
Quand on m'a dit en trois pages que Bars fonctionnait bien. J'ai changé de barre maximale sans réfléchir et j'ai essayé de vérifier. Comme je ne voyais pas le lien, je n'ai pas écrit que sans recharger le terminal, j'inventais tout...
Je n'utilise pas Bars, mais c'était peut-être le problème. Parce que je ne pouvais pas le reproduire le jour suivant. Et je ne suis plus allé dans les paramètres, j'ai toujours l'illimité.
C'est juste pour les développeurs, ça peut être utile.
Je me suis aussi souvenu.
Quand on m'a dit sur trois pages que les barres étaient bien. J'ai changé de barre maximale sans réfléchir et j'ai essayé de vérifier. Comme je n'ai pas vu la connexion, je n'ai pas écrit que sans recharger le terminal, tout était composé...
Je n'utilise pas Bars, mais c'était peut-être le problème. Parce que je ne pouvais pas le reproduire le jour suivant. Et je n'ai plus fait de réglages, j'ai toujours été illimité.
C'est juste une information pour les développeurs, qui peut être utile.
Je n'utilise pas prev_calculé régulier depuis longtemps, je déclare globalement prev_calc et compte avec (je vis heureux et suis très gros :)
Même si, bien sûr, ce bug doit être corrigé. Au moins si le taux_total n'a pas changé, alors remettez prev_calculated à zéro, mais s'il a changé pour une valeur plus petite, alors vous devez le faire.
Je n'utilise pas prev_calculé régulier depuis longtemps, je déclare prev_calc globalement et le prend en compte (je vis heureux et suis très gros :)
...
Merci, c'est pour la documentation :)
Merci, cela va dans la documentation :)
C'est au ServiceDesk.
On leur a déjà tout dit.
Vous êtes juste un programmeur trop mature pour apprécier la valeur de votre conseil. Pour moi, en tant qu'éternel nigaud, c'est à la limite de la découverte :) donc de la documentation (personnelle).
On leur a déjà tout dit.
Vous êtes juste un trop vieux programmeur pour apprécier la valeur de vos conseils. Pour moi, en tant qu'éternel nigaud - c'est à la limite de la découverte :) donc dans la documentation (personnelle).
Dans votre documentation personnelle, alors, il y a ça.
Lancement forcé du recalcul si l'historique a été réduit à des barres maximales dans la fenêtre et que le taux_total est devenu inférieur.
L'erreur n'est pas critique (elle sera corrigée sur le prochain tick), mais sur le même tick où l'historique a été coupé, il y aura un décalage du graphique dû à l'inadéquation et le recalcul sera bloqué par la condition de cycle parce que prev_cal>rates_total et cela signifie qu'il n'y aura pas d'entrée dans le cycle.
Eh bien, dans la documentation personnelle, il y a ceci.
Lancement forcé du recalcul si l'historique a été réduit à des barres maximales dans la fenêtre et que le taux_total est devenu inférieur.
L'erreur n'est pas critique (elle sera corrigée au prochain tick), mais au même tick où l'historique a été rogné, il y aura un décalage du graphique dû à l'inadéquation et le recalcul sera bloqué par la condition de cycle parce que prev_cal>rates_total et donc il n'y aura pas d'entrée dans le cycle.
Ok, merci.
Si je comprends bien, il y a une erreur dans l'aide