Erreurs, bugs, questions - page 1667
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
Bien sûr, je ne comprends pas grand chose, mais je pense, pour une raison quelconque, que les copies d'indicateurs créées par différents "maîtres", même avec les mêmes paramètres et appliquées à un seul et même graphique, auront des poignées différentes. En principe, ils ne sont pas au courant de la copie existante de l'indicateur, et ils ne devraient pas l'être. Lors du dessin, ils se superposeront simplement les uns aux autres.
Je peux me tromper. Mais la logique suggère qu'il doit en être ainsi, comme écrit dans le paragraphe précédent.
Je ne suis certainement pas un développeur MQ, mais d'après ce qu'on m'a expliqué, Five a effectué une mise en cache efficace des indices, de sorte qu'il n'y aura toujours qu'un "même" indentation, et que plusieurs "maîtres" auront un lien avec elle. Les poignées seront peut-être différentes - je n'ai pas vérifié - mais à l'intérieur, ce sera la même entité. Personne n'a dit qu'ils devraient être au courant de la copie qui existe déjà - s'il vous plaît, ne spéculez pas. Absolument, personne d'autre que l'"hôte" ne connaît ses indicateurs, et pour un indicateur, un compte de référence est maintenu pour lui à partir de différents "hôtes", mais il ne connaît pas les hôtes.
Comme le montre la pratique, la logique varie d'une personne à l'autre. Par exemple, très souvent, ma logique ne coïncide pas avec celle de MQ, mais ici je ne fais que raconter ce que j'ai entendu de leur part.
Je ne suis certainement pas un développeur MQ, mais d'après ce qu'on m'a expliqué, Five a effectué une mise en cache efficace des indices, de sorte qu'il n'y aura toujours qu'un "même" indentation, et que plusieurs "maîtres" auront un lien avec elle. Les poignées seront peut-être différentes - je n'ai pas vérifié - mais à l'intérieur, il s'agira de la même entité. Personne n'a dit qu'ils devraient être au courant de la copie qui existe déjà - s'il vous plaît, ne spéculez pas. Absolument, personne d'autre que l'"hôte" ne connaît ses indicateurs, et pour un indicateur, un compteur de référence est maintenu pour lui depuis différents "hôtes", mais il ne connaît pas les hôtes.
Comme le montre la pratique, la logique varie d'une personne à l'autre. Par exemple, très souvent, ma logique ne coïncide pas avec celle de MQ, mais ici je ne fais que raconter ce que j'ai entendu de leur part.
Toutes les fonctions comme iMA, iAC, iMACD, iIchimoku, etc., créent une copie de l'indicateur technique approprié dans le cache global du terminal client. Si une copie de l'indicateur avec ces paramètres existe déjà, une nouvelle copie n'est pas créée, mais le compteur de références à cette copie est augmenté.
J'ai réussi à réaliser un script de test proche du programme source avec une erreur lors de l'exécution
Résultat : appel de pointeur de fonction invalide dans 'Script2.mq5'.
construire 1405. L'erreur elle-même demeure - déplacée vers une autre partie du programme - je m'en occuperai plus tard.
Mais de nouveaux sont apparus, qui n'existaient pas auparavant.
Résultat : fichier EX5 invalide (8)Comment rendre les éléments du tableau Shift+F9 visibles dans le débogage ?
En fait, dans 99 % des cas, l'appel à IndicatorRelease est une erreur logique du programmeur.
La création d'indicateurs est l'une des opérations les plus coûteuses qui mettent en jeu des mécanismes très profonds de leur calcul. Tenter de fermer une poignée d'indicateur est également une opération très coûteuse, si l'on pense aux véritables processus sous-jacents de sa mise en œuvre. La création et la fermeture fréquentes d'indicateurs montrent que le développeur ne comprend pas du tout l'essence des opérations.
Il est très facile à comprendre.
Est-ce que je comprends bien qu'en utilisant iCustom au lieu d'IndicatorCreate, l'utilisateur transfère la responsabilité d'IndicatorRelease à la solution universelle (donc non optimale) des développeurs ?
Dans lequel les indicateurs créés sont stockés pendant un certain temps, tandis qu'ils sont appelés avec une certaine fréquence. S'ils ne sont pas appelés pendant un certain temps, alors il y a un IndicatorRelease forcé. N'est-ce pas ?
Autrement dit, iCustom doit être utilisé de manière optimale, en tenant compte du juste milieu entre la complexité de la mise en œuvre et les performances. Mais si vous voulez la vitesse maximale, il vaut mieux essayer de tout faire par IndicatorCreate, en créant votre propre algorithme d'indicateurs plus rapide (pas universel), en connaissant les particularités de leur utilisation.
Ai-je bien compris ?
Est-ce que je comprends bien qu'en utilisant iCustom au lieu d'IndicatorCreate, l'utilisateur transfère la responsabilité d'IndicatorRelease à la solution universelle (donc non optimale) des développeurs ?
Dans lequel les indicateurs créés sont stockés pendant un certain temps, tandis qu'ils sont appelés avec une certaine fréquence. S'ils ne sont pas appelés pendant un certain temps, alors il y a un IndicatorRelease forcé. N'est-ce pas ?
Autrement dit, iCustom doit être utilisé de manière optimale, en tenant compte du juste milieu entre la complexité de la mise en œuvre et les performances. Mais si vous voulez la vitesse maximale, il vaut mieux essayer de tout faire par IndicatorCreate, en créant votre propre algorithme d'indicateurs plus rapide (pas universel), en connaissant les particularités de leur utilisation.
Ai-je bien compris ?
Non, vous ne l'êtes pas.
Les deux fonctions sont absolument égales. Les deux fonctions renvoient le manche de l'indicateur
Non, c'est faux.
Les deux fonctions sont absolument égales. Les deux fonctions renvoient le manche de l'indicateur
IndicatorRelease doit être fait après iCustom ?
En fait, il s'avère qu'il est tout à fait possible d'exécuter des EAs MT4 dans MT5. Pour ceux qui n'utilisent pas d'autres indicateurs en interne - très facile. Ceux qui les utilisent - créent un analogue du stockage MT4-iCustom. La question de l'impréparation des données est également tout à fait possible.
Ecrivez un tel adaptateur et tout indicateur MT4 fonctionnera avec succès dans MT5. Mais dans ce cas, Nikolay Kositsyn perdra son emploi... Non, il vaut mieux pas.
IndicatorRelease doit être fait après iCustom ?
En fait, il s'avère qu'il est tout à fait possible d'exécuter des EAs MT4 dans MT5. Pour ceux qui n'utilisent pas d'autres indicateurs en interne - très facile. Ceux qui les utilisent - créent un analogue du stockage MT4-iCustom. La question de l'impréparation des données est également tout à fait possible.
Ecrivez un tel adaptateur et tout indicateur MT4 fonctionnera avec succès dans MT5. Mais dans ce cas, Nikolay Kositsyn perdra son emploi. Non, je ne préfère pas.
Je me souviens, la documentation dit qu'il est préférable d'initialiser (créer) les poignées d'indicateurs dans la fonction OnInit, et d'effectuer IndicatorRelease dans la fonction OnDeinit. Cela signifie que pendant toute la durée de fonctionnement du conseiller expert, les manipulations des indicateurs restent pertinentes.
Pas seulement à jour, mais recalculé (enfin, ou en extrayant des données pour les recalculer) ! C'est pourquoi il est toujours judicieux d'utiliser IndicatorRelease si vous êtes sûr à 100% de ne plus en avoir besoin. Et cela peut arriver bien avant OnDeinit.
Par exemple, si vous appelez un indicateur avec des paramètres d'entrée aléatoires à chaque fois, il n'y a aucun intérêt à ne pas faire IndicatorRelease.