Bogue MQL5 lors du travail avec l'accès aux séries chronologiques iClose/iOpen, etc. - page 2
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
Alors dites-moi pourquoi le gel se produit dans mon cas ? J'ai un gel des données dans OnTick avant la fonction d'interrogation de l'indicateur, c'est-à-dire que la mise à jour de CopyTime par M1 agit comme un déclencheur pour démarrer d'autres traitements dans OnTick, et avant CopyTime aucune fonction ou interrogation d'indicateur.
Et pourquoi il n'y avait pas de tels problèmes avant la 30ème build et depuis octobre 2017 tout fonctionnait bien ?
Faites ce que je vous ai conseillé.
Sinon, il faut des matériaux complets pour une lecture à 100%.Pourquoi les développeurs n'écrivent-ils pas une fonction qui garantit un tableau de données synchronisé (à travers plusieurs outils) afin que les gens ne s'embêtent pas et perdent leur temps en vain ?
Après tout, MT5 est positionné comme un outil cool et pratique, n'est-ce pas ?
Je suis très impatient...
Il a également toujours été recommandé, si vous travaillez avec le cadre temporel de quelqu'un d'autre, d'obtenir l'OHLC de ce cadre temporel une fois par minute (n'importe quelle fonction CopyXXXX). Cela a toujours été le cas.
Slava a dit une fois toutes les deux minutes. J'ai la flemme de chercher, mais je me souviens exactement.
Pourquoi les développeurs n'écrivent-ils pas une fonction qui garantit un tableau de données synchronisé (à travers plusieurs outils) afin que les gens ne s'embêtent pas et perdent leur temps en vain ?
Après tout, MT5 est positionné comme un outil cool et pratique, n'est-ce pas ?
nous attendons...
Oui. Le constructeur OnCalculate pour le nombre de symboles et d'échéances requis. Ou, en plus de OnCalculate, introduire un nouvel objet, par exemple "MainCalculate" pour un maximum de 255 OnCalculate, dans lequel vivent les objets OnCalculate - qui n'en a pas besoin, utilise l'ancien OnCalculate, qui a besoin de mtf et de symboles différents utilise "MainCalculate". Le premier et le dernier tick de la barre sont les mêmes pour tous les symboles et toutes les périodes coïncidentes. Puisque OnCalculate a déjà été développé et établi, il est logique de sortir tous les appels à des symboles et des délais tiers par l'intermédiaire de l'agrégation OnCalculate sans que d'autres fonctions servent d'intermédiaire aux délais et aux symboles.
Pensez à l'endroit où les données (en particulier les données garanties) seront disponibles lorsque vos indicateurs sont insupportablement lents, prenant des centaines de millisecondes, voire des secondes, pour recevoir/présenter les ticks par tick. Par conséquent, aucune unité centrale n'est suffisante en temps pour traiter les ticks, ce qui se traduit par un déficit accumulé et un décrochage correspondant dans l'historique du graphique.
Lorsque vous demandez un "don garanti", il s'agit très probablement d'une demande de "je ne veux rien savoir, je veux continuer à écrire comme je le veux, je ne veux pas penser aux performances et aux verrous, donnez simplement" ?
Lorsque vous disposez de millions de barres, pensez à la performance de vos indicateurs et de ceux des autres. Un indicateur mal écrit et coûteux peut facilement ralentir la mise à jour des graphiques de ses symboles.
Pour commencer, mesurez le temps de réponse de OnCalculate en microsecondes. Divisez ensuite 1 seconde par le temps de réponse moyen des ticks pour obtenir la répartition maximale de l'indicateur en ticks par seconde.
Cela donne immédiatement à réfléchir.
Toutes les deux minutes, Slava a dit. Je suis trop paresseux pour le chercher, mais je me souviens exactement.
Je m'en souviens, mais j'utilise toujours un intervalle d'une minute. C'est plus fiable de cette façon.
Excusez-moi, mais dans ce cas la profondeur de l'historique sur l'échelle de temps M15 était de 120 barres et quoi, c'est déjà critique pour MQL5 ?
Vous n'avez pas fourni de matériel reproductible.
J'ai expliquépourquoi les fonctions d'accès aux données d'autres personnes seront retardées lorsque leurs symboles comportent des indicateurs de retard. Vous parlez de votre cas particulier d'appel, en ignorant complètement la présence d'autres indicateurs sur les graphiques. Et c'est par eux que vous auriez dû commencer, d'autant plus que j'en parle clairement.
Ne vous lancez pas dans la démagogie et les déclarations comparatives avec une absence totale d'actes techniques et de listes d'indicateurs avec des experts.
Donnez-moi le code à reproduire, s'il vous plaît.
***
Alors comment le repasser ? Veuillez me donner les données pour la lecture.
Bien sûr, je ne peux pas mettre tout le code ici, mais j'ai déjà indiqué la partie où le problème se produit, alors je vais le faire à nouveau :
Soit le code entier, soit ne rien dire. Sans le code complet, c'est juste beaucoup d'air.
Pensez à l'endroit où les données (d'autant plus garanties) seront disponibles, lorsque vos indicateurs sont insupportablement lents à recevoir/appliquer des ticks, passant des centaines de millisecondes voire des secondes pour un tick. En conséquence, aucune unité centrale n'a le temps de traiter les ticks, ce qui se traduit par un déficit accumulé et un décrochage correspondant dans l'historique du graphique.
Lorsque vous demandez un "don garanti", il s'agit très probablement d'une demande de "je ne veux rien savoir, je veux continuer à écrire comme je le veux, je ne veux pas penser aux performances et aux verrous, donnez simplement" ?
Lorsque vous disposez de millions de barres, pensez à la performance de vos indicateurs et de ceux des autres. Un indicateur mal écrit et coûteux peut facilement bloquer les mises à jour des graphiques de son symbole.
Commencez par mesurer le temps de réponse de OnCalculate en microsecondes. Divisez ensuite 1 seconde par le temps de réponse moyen des ticks pour obtenir le débit maximal de l'indicateur en ticks par seconde.
Cela donne immédiatement à réfléchir.
Vous n'avez pas toujours besoin de la super vitesse, la facilité d'utilisation est très importante, aujourd'hui le processus d'écriture d'indicateurs multi-devises est comme un "coucher de soleil à la main", même dans MT4 il était plus facile, parce que là vous pouvez toujours l'obtenir par les i-fonctions, même si lentement, mais vous pouvez l'obtenir, mais dans MT5 les données sont soit là ou pas, et vous devez créer un code spécial par vous-même.
En outre, vous devez garder à l'esprit que tous les utilisateurs ne sont pas des programmeurs de haut niveau, certaines personnes ont simplement besoin d'un outil pratique et fiable, même s'il n'est pas supersonique, et une telle vitesse n'est généralement pas nécessaire pour les systèmes de portefeuille, et le débit maximal n'est pas critique dans ce cas, l'important est que le fonctionnement soit garanti et facile, en fait, c'est le facteur qui rend le produit plus populaire et accessible.
L'apparition des i-fonctions dans mt5 a quelque peu amélioré la situation, mais n'a pas résolu le problème, il n'y a aucune possibilité d'obtenir facilement et simplement un tableau synchronisé pour plusieurs instruments, peut-être que ce n'est pas nécessaire pour tout le monde, peut-être que ce n'est même pas une priorité, je peux le comprendre, mais néanmoins il y a une telle tâche.
Fonction : GetSyncData
Entrée : liste de symboles, cadre temporel, plage de barres et/ou plage de dates.
Sortie : tableau avec des éléments MqlRates de sorte que les index de tous les symboles correspondent au même temps.