Séquence d'exécution de Init() et DeInit() - page 10
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
J'ai clairement écrit - gardez les données que vous devez transférer à la copie toujours à jour, vous ne devez pas le faire seulement quand vous êtes initiés, gardez-les toujours à jour.
Andrey, vous plaisantez ou vous ne comprenez vraiment pas que toutes vos données réelles stockées dans des variables et des tableaux dans les indicateurs deviennent sans intérêt après le changement de TF parce que la copie de l'indicateur avec tous ses détails est supprimée. Dans les Expert Advisors, bien sûr, tout est simple, car il n'y a pas de réinitialisation.
Vous devez plaisanter ou vous ne comprenez pas que toutes vos données réelles stockées dans des variables et des tableaux dans les indicateurs deviennent sans intérêt après le changement de TF parce que la copie de l'indicateur avec tous ses détails est supprimée. Dans les Experts, bien sûr, tout est simple, car il n'y a pas de réinitialisation.
Non, je ne le suis pas.
Vous ne comprenez pas ce que je dis.
Par exemple, un certain ensemble de données doit être transféré vers une autre copie de l'indicateur (qu'il s'agisse d'un autre indicateur jeté sur un graphique ou d'une nouvelle copie de l'indicateur lorsque la TF change, peu importe). L'indicateur calcule quelque chose et chaque fois qu'il calcule quelque chose et que ce quelque chose sera appliqué à d'autres indicateurs, cet indicateur doit être mis à jour. A chaque fois. Cette base de données peut être stockée à différents endroits, en fonction de la quantité de données et de la vitesse de communication requise. Ces données doivent être mises à jour chaque fois que nécessaire après une modification des données, et pas seulement lorsqu'elles sont désinitialisées. C'est ça l'astuce. Il n'y a rien de compliqué. Il ne s'agit pas de stocker les données dans les variables locales de l'indicateur, mais de réinitialiser/mettre à jour les données chaque fois qu'elles ont été recalculées.
Mais avec les objets graphiques, c'est très simple.
Dans les Expert Advisors, bien sûr, tout est simple, car il n'y a pas de réinitialisation.
Non, je ne le suis pas.
Vous ne comprenez pas ce que je dis.
Par exemple, un certain ensemble de données doit être transféré vers une autre copie de l'indicateur (qu'il s'agisse d'un autre indicateur jeté sur un graphique ou d'une nouvelle copie de l'indicateur lorsque la TF change, peu importe). L'indicateur calcule quelque chose et chaque fois qu'il calcule quelque chose et que ce quelque chose sera appliqué à d'autres indicateurs, cet indicateur doit être mis à jour. A chaque fois. Cette base de données peut être stockée à différents endroits, en fonction de la quantité de données et de la vitesse de communication requise. Ces données doivent être mises à jour chaque fois que nécessaire après une modification des données, et pas seulement lorsqu'elles sont désinitialisées. C'est ça l'astuce. Il n'y a rien de compliqué. Il ne s'agit pas de stocker des données dans des variables locales de l'indicateur, mais de réinitialiser/mettre à jour les données chaque fois qu'elles ont été recalculées.
Et avec les objets graphiques, c'est très simple, il n'y a même pas besoin de l'expliquer.
Le fait que rien ne soit compliqué est très discutable. Essayez de reproduire réellement sur l'exemple d'une machine à onduler simple ce que j'ai mis en œuvre dans ce produit. Dans le bracelet, vous modifiez la période à l'aide de votre souris. Lorsque vous changez de TF, les modifications doivent être enregistrées et vous pouvez utiliser plusieurs indicateurs dans la fenêtre. Et vous verrez qu'il n'y a rien de compliqué. Et si vous avez besoin de passer un tableau. Et vous verrez comme c'est "simple". Je le penserais peut-être moi-même, si je ne l'ai pas déjà mis en œuvre.
Le fait que rien ne soit difficile est très discutable. Essayez de reproduire réellement sur l'exemple d'une simple épave ce que j'ai mis en œuvre dans ce produit. Dans le bracelet, vous modifiez la période à l'aide de la souris. Lorsque vous changez de TF, les modifications doivent être enregistrées et il est possible d'utiliser plusieurs indicateurs dans la fenêtre. Et vous verrez qu'il n'y a rien de compliqué. Et si vous avez besoin de passer un tableau. Et vous verrez comme c'est "simple".
Je n'ai découvert que récemment que toutes les variables sont sauvegardées dans les EA lors de la réinitialisation, c'est-à-dire que j'ai écrit les EA de la même manière que les indicateurs, en supposant que le programme ne sait rien des autres programmes, car il n'y a que leur init et deinit, le programme ne doit pas savoir les init et deinit des autres programmes.
C'est pourquoi je ne me fie jamais à la cohérence temporelle de l'ininit et du deinit du programme à décharger et à exécuter à nouveau, je ne me fie jamais au fait qu'elle peut changer parfois (en 1580, elle a changé). S'appuyer sur des bogues non documentés et sur l'avenir de la plate-forme peut se retourner contre vous à l'avenir.
Dans ma pratique, il existe également des produits qui modifient dynamiquement la visualisation en fonction des actions de l'utilisateur, en appliquant tout - des événements aux fichiers d'échange. En règle générale, il y a beaucoup plus d'indicateurs sur le graphique que dans 1. Les tampons d'indicateurs dans 5 sont illimités et vous pouvez les créer en tant que paramètre pendant le démarrage. C'est-à-dire que nous sommes des personnes créatives, nous devons avoir une approche flexible pour résoudre nos tâches et en même temps garder à l'esprit les spécificités de 3 types de programmes, mais les développeurs de plate-forme sont concernés par d'autres questions, qui sont plus importantes que les difficultés mineures par rapport aux tâches globales de la plate-forme.
Il y a des défauts vraiment importants dans la plate-forme, dont ils ne parlent pas beaucoup ou pas du tout, c'est beaucoup plus important que le problème farfelu des "inits et deinserts".
Si le délai est basculé vers le bas, OnInit sur le délai le plus bas (nouveau) d'abord et ensuite OnDeinit sur le délai le plus haut (ancien).
Si l'interrupteur va vers le haut, alors c'est l'inverse. D'abord OnDeinit sur l'ancien cadre temporel (inférieur), puis OnInit sur le nouveau cadre temporel (supérieur).
Ici, nous devons garder à l'esprit que les caches sont traités de la plus petite à la plus grande période de temps.
C'est juste horrible. Les programmeurs d'applications ne doivent pas penser à des choses aussi systémiques. La plateforme peut gérer les caches en interne comme elle le souhaite, mais au niveau du MQL, elle doit tout regrouper de manière transparente dans un seul contrat d'événement, sans effets secondaires potentiels. Toutes les références à de prétendues considérations d'efficacité et à la possibilité pour chacun de contourner le problème par lui-même sont tout simplement indéfendables. Il est possible de faire les deux efficacement et commodément (en éliminant complètement la possibilité de marcher sur ce râteau), une fois pour toutes.
C'est vrai, ils ne devraient pas. Vous exécutez donc Total Commander, par exemple. Pourquoi exiger de Microsoft que Windows s'occupe de la séquence "correcte" de chargement/ déchargement des copies de TC dans la RAM ? Est-ce une préoccupation de l'OS ?
Le souci de l'OS est que le CT n'interfère pas avec les autres CT et que ce qu'ils y font en RAM, échange de fichiers ou autre, ne regarde qu'eux.
"Je pense que oui !" (c) Mimino, 1977.
Je voudrais résumer et résumer ce qui précède. Donc, avant la sortie de la version 1580 de MT5 (version actuelle 1571), qu'avons-nous ?
Dans les indicateurs, contrairement aux Expert Advisors, quand le TF change, parce que"une nouvelle copie de l'indicateur est créée, qui ne sait rien de la copie précédente", toutes les variables sont réinitialisées, en plus l'ordre d'exécution de OnDeinit de l'ancien TF et OnInit du nouveau TF est imprévisible, indépendamment du fait que le TF soit "up" ou "down" (pratique, contrairement à ce qui a été mentionné par M. Slava). Dans ce contexte, les programmateurs sont confrontés à un certain nombre de problèmes et d'incertitudes. Par exemple :
- le programmeur, qui n'a pas lu ce sujet, crée un objet pour quelque chose dans OnInit, et il est logique de vérifier l'existence de l'objet avec ce nom avant de le créer. Il est également logique de prescrire la suppression de cet objet dans OnDeinit. Lorsque le TF est modifié, si le premier OnInit du nouveau TF est exécuté, il vérifie l'existence de l'objet, il s'avère qu'il existe déjà, et il n'est pas créé, car il est déjà créé. Ensuite, le OnDeinit de l'ancien TF est effectué et l'objet est supprimé. Le programmeur est en état de choc. Où est mon objet et pourquoi a-t-il disparu ? Il sera encore plus confus, lorsque la prochaine fois que le TF est modifié, lorsque la séquence de OnInit et OnDeinit est différente, l'objet n'est pas supprimé. C'est supprimé, ce n'est pas supprimé.... Après une longue recherche, vous commencerez à adresser au Service Desk de nouveaux sujets sur le forum à propos de l'ancien.
Ce n'est que la situation la plus simple. Il y en aura d'autres car cette fonctionnalité n'est pas décrite dans la documentation et vous ne pouvez en prendre connaissance que sur le forum.
Si vous voulez créer quelque chose de spécial et passer certains paramètres de l'ancienne copie de l'indicateur à la nouvelle, lorsque vous changez le TF, vous ne pouvez pas utiliser OnDeinit, à cause de la séquence imprévisible des opérations d'initialisation et de désinitialisation. A monavis, la meilleure solution dans ce cas est d'utiliser les outils suivants :ResourceCreate basé sur le tableau de pixels etResourceReadImage, mais c'est assez lourd et vous devez faire attention aux conflits de ressources, si vous utilisez plusieurs indicateurs identiques dans une fenêtre, et chaque fois que les données que vous voulez envoyer pour une autre copie doivent être sauvegardées dans une ressource non réinitialisée, parce que le moment du changement possible de TF n'est pas connu pour l'application. Je l'ai mis en œuvre il y a longtemps (par exemple dans ce produit), je sais donc de quoi je parle. La mise en œuvre du transfert de données par le biais de fichiers et de variables globales du terminal est une solution moins efficace (IMHO).
Si la nouvelle build 1580 seracomme le dit Slava, cela ne facilitera pas la tâche, car la désinitialisation de l'ancienne copie de l'indicateur sera effectuée après l'initialisation d'une nouvelle copie. Mais il n'y aura pas d'incertitude.
Il faut espérer que les développeurs ont prêté attention à ce problème puisqu'ils essaient de le corriger.
Nous attendons une nouvelle construction.
Je suis tout à fait d'accord que cette fonction de traitement DOIT être mentionnée dans la documentation, sinon les nouveaux arrivants seront confrontés à ce problème et viendront sur les forums à la recherche d'une solution. (Pourquoi, alors que vous pouvez leur en parler tout de suite dans les docs Terminal et MQL).
Ajoutez également à la documentation que le journal ne donne pas une image complète des événements, mais seulement une partie. Voir les journaux complets pour une image complète.
Pour le reste, plus tard ...
Je voudrais résumer et résumer ce qui précède. Donc, avant la sortie de la version 1580 de MT5 (version actuelle 1571), qu'avons-nous ?
Dans les indicateurs, contrairement aux Expert Advisors, quand le TF change, parce que"une nouvelle copie de l'indicateur est créée, qui ne sait rien de la copie précédente", toutes les variables sont réinitialisées, en plus l'ordre d'exécution de OnDeinit de l'ancien TF et OnInit du nouveau TF est imprévisible, indépendamment du fait que le TF soit "up" ou "down" (pratique, contrairement à ce qui a été mentionné par M. Slava). Dans ce contexte, les programmateurs sont confrontés à un certain nombre de problèmes et d'incertitudes. Par exemple :
- le programmeur, qui n'a pas lu cette rubrique, en créant un indicateur pour quelque chose dans OnInit, crée un objet, en vérifiant logiquement avant la création de l'objet avec ce nom. Il est également logique de prescrire la suppression de cet objet dans OnDeinit. Lorsque le TF est modifié, si le premier OnInit du nouveau TF est exécuté, il vérifie l'existence de l'objet, il s'avère qu'il existe déjà, et il n'est pas créé, car il est déjà créé. Ensuite, le OnDeinit de l'ancien TF est effectué et l'objet est supprimé. Le programmeur est en état de choc. Où est mon objet et pourquoi a-t-il disparu ? Il sera encore plus confus, lorsque la prochaine fois que le TF est modifié, lorsque la séquence de OnInit et OnDeinit est différente, l'objet n'est pas supprimé. C'est supprimé, ce n'est pas supprimé.... Après une longue recherche, vous commencerez à adresser au Service Desk, de nouveaux fils de discussion sur le forum à propos de l'ancien.
Ce n'est que la situation la plus simple. Il y en aura d'autres car cette fonctionnalité n'est pas décrite dans la documentation et vous ne pouvez en prendre connaissance que sur le forum.
Si vous voulez créer quelque chose de spécial et passer certains paramètres de l'ancienne copie de l'indicateur à la nouvelle, lorsque vous changez le TF, vous ne pouvez pas utiliser OnDeinit, à cause de la séquence imprévisible des opérations d'initialisation et de désinitialisation. A monavis, la meilleure solution dans ce cas est d'utiliser les outils suivants :ResourceCreate basé sur le tableau de pixels etResourceReadImage, mais c'est assez lourd et vous devez faire attention aux conflits de ressources, si vous utilisez plusieurs indicateurs identiques dans une fenêtre, et chaque fois que les données que vous voulez envoyer pour une autre copie doivent être sauvegardées dans une ressource non réinitialisée, parce que le moment du changement possible de TF n'est pas connu pour l'application. Je l'ai mis en œuvre il y a longtemps (par exemple dans ce produit), je sais donc de quoi je parle. La mise en œuvre du transfert de données par le biais de fichiers et de variables globales du terminal est une solution moins efficace (IMHO).
Si la nouvelle build 1580 seracomme le dit Slava, cela ne facilitera pas la tâche, car la désinitialisation de l'ancienne copie de l'indicateur sera effectuée après l'initialisation d'une nouvelle copie. Mais au moins, il n'y aura pas d'incertitude.
J'espère que les développeurs ont prêté attention à ce problème puisqu'ils essaient de le corriger.
Nous attendons une nouvelle construction.
L'Expert Advisor fonctionne bien lorsqu'on change de TF, et l'indicateur dans cette situation fonctionne très différemment.
Aucun problème si vous êtes conscient de cette fonctionnalité non documentée et que vous ne traitez que le cas le plus simple - le graphique. objets. Je veux dire ceux qui ne connaissent pas cette fonctionnalité, je pense que ce sujet sur ce forum sera lu par un très petit pourcentage de programmeurs et je plains le temps qu'ils passent à comprendre toutes les nuances. J'avais été dans cette situation avant d'en comprendre l'essence.