Bogue MQL5 lors du travail avec l'accès aux séries chronologiques iClose/iOpen, etc. - page 7
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
1) Mesurer le temps d'exécution par calcul OnTick/OnCalculate en microsecondes et les afficher dans le journal.
Ainsi, vous pouvez voir combien de temps il vous faut pour calculer un seul tick. Estimez ensuite combien de tics à cette vitesse vous pouvez compter par seconde. Il ne s'agira probablement pas de plus d'une douzaine de tics, et il y a sciemment plus de tics par seconde.
2) Mesurez le temps pour chaque OnCalcul sur les indicateurs qui sont attachés aux graphiques/horaires dont vous extrayez les données.
Il y a probablement une situation similaire là-bas. En raison de la lenteur des calculs, le terminal attend que le symbole calculé:timeframe soit déverrouillé. Ce sont les indicateurs lents, surtout sur un historique profond, qui conduisent à figer les graphiques des autres traders.
Lorsque vous concevez des indicateurs, vous devez accorder la priorité aux questions de performance et aux recalculs économiques. Sinon, vous allez tuer tout ce qui vous entoure.
Renat, c'est vraiment très triste. Est-ce que Tiki attend maintenant que je règle mes problèmes ? Jusqu'à présent, je supposais que les tics étaient auto-générés, et que j'avais le temps ou pas. Maintenant, il s'avère que je peux suspendre le système.
Renate, ça a été assez triste. Est-ce que les tics attendent maintenant que je règle mes problèmes ? Jusqu'à présent, je supposais que les tics se généraient d'eux-mêmes, et que j'avais le temps ou pas. Maintenant, il s'avère que je peux suspendre le système.
L'indicateur fonctionne à chaque tic, sans saut. Vous devez surveiller la durée de OnCalculate et la fréquence des ticks qui arrivent en permanence. Sinon, vous obtiendrez un blocage.
La façon la plus simple de le reproduire est d'exécuter l'indicateur sur un symbole personnalisé et de commencer à le taper avec une certaine fréquence. Plus la fréquence augmente, plus le freinage est important. C'est tout à fait logique.
Dans quels cas l'indicateur ne peut pas dessiner sa valeur ? Les tampons sont remplis de valeurs valides, mais le graphique de l'indicateur est vide..... au moins ce n'est pas vice versa. construisez 1940
1944 le même. Il doit en être ainsi.
L'indicateur est exécuté à chaque tick, sans saut. Vous devez surveiller en permanence la durée de OnCalculate et le taux d'arrivée des tics. Sinon, vous obtiendrez un blocage.
La façon la plus simple de le reproduire est d'exécuter l'indicateur sur un symbole personnalisé et de commencer à le ticoter avec une certaine fréquence. Plus la fréquence augmente, plus le freinage est important. Tout a un sens.
Oui, exactement comme ça.
Renate, ça a été assez triste. Est-ce que les tics attendent maintenant que je règle mes problèmes ? Jusqu'à présent, je supposais que les tics se généraient d'eux-mêmes, et que j'avais le temps ou pas. Maintenant il s'avère que je peux accrocher le système.
Les tiques ont toujours été en attente. Nous garantissons l'appel de OnCalculate à chaque tic.
Alors qu'à quatre, l'interface graphique se figeait, à cinq, il s'agit simplement d'un retard dans le traitement d'un caractère particulier par un thread individuel. Et c'était toujours comme ça à cinq. C'est juste que vous ne l'avez vu que maintenant.
Le gel de la mise à jour du délai invisible des aliens après la reconnexion a été résolu et corrigé. La raison en était des statuts de cache erronés après la reconnexion.
La version bêta 1946 est disponible via Aide -> Vérifier les mises à jour du bureau -> Dernière version bêta.
Mis à jour, testons-le.
La question est de savoir si le problème actuel était également lié aux cas de chargement d'autres outils (cadre temporel invisible), je veux dire les indicateurs multidevises et les EA, ou si ces problèmes ne sont pas liés entre eux ?
Les tiques ont toujours été en attente. Nous garantissons l'appel de OnCalculate à chaque tic.
Si en quatrième position, cela gèlerait l'interface graphique, mais en cinquième position, il s'agit juste d'un retard d'un thread séparé traitant un caractère particulier. Et c'était toujours comme ça en cinquième. C'est juste que vous ne l'avez vu que maintenant.
Y aura-t-il un message dans le journal du terminal à propos de cette situation, quelque chose comme "l'indicateur est trop lent" ?
?
Y aura-t-il un message dans le journal du terminal à propos de cette situation, tel que "l'indicateur est trop lent" ?
?
Dans le journal des experts
Merci, c'est quelque chose, mais je comprends qu'il n'est pas possible de déterminer par programme que l'indicateur calcule des ticks qui ne sont pas pertinents et que l'indicateur raccroche le fil du terminal ?
Merci, c'est quelque chose, mais je comprends que vous ne pouvez pas déterminer par programme que l'indicateur calcule des ticks qui ne sont pas pertinents et que l'indicateur raccroche le fil du terminal ?
Il est possible d'essayer de déterminer.
S'il s'agit de minutes, vous pouvez comparer l'heure de la dernière barre avec TimeCurrent(). Si ce n'est pas M1, vous pouvez demander iTime(_Symbol,PERIOD_M1,0) et comparer avec TimeCurrent().
Vous pouvez comparer le cours acheteur ou le dernier cours (selon le symbole) avec le cours de clôture de la dernière barre. Vous pouvez demander directement à SymbolInfoTick le symbole actuel. En plus de l'offre et de la demande, il y a aussi le temps de tic-tac.