Séquence d'exécution de Init() et DeInit() - page 5
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
Je comprends cela. Je demandais la logique de la séquence des opérations. Et nous sommes en train de le rater. Parfois, OnDeinit est exécuté en premier (comme il se doit selon la logique d'un profane) et parfois OnInit est exécuté en premier.
Je comprends que la réponse se trouve dans la ligne"Pendant un certain temps (un temps très court) les deux copies de l'indicateur existent en parallèle". Mais cela ne rend pas la question plus claire.
La fonction OnInit doit être exécutée en premier dans le programme.
Pouvez-vous donner un exemple où la séquence OnInit -> OnDeinit n'est pas toujours exécutée ?
La fonction OnInit est censée être exécutée en premier dans le programme.
Pouvez-vous donner un exemple où OnInit -> OnDeinit n'est pas toujours exécuté ?
Vous pouvez utiliser l'exemple de l'auteur du thèmeERROR.mq5, qu'il donne au début. Changez le TF et voyez ce qui se passe dans l'onglet Experts.
Vous pouvez utiliser l'exempleERROR.mq5 qu'il donne au début
Je vais l'essayer dans le courant de la journée. L'avez-vous déjà utilisé personnellement ?
Bien sûr, je l'ai utilisé il y a 9 mois. Vous pouvez lire mon commentaire au numéro 8 de ce fil.
Er, non, ce n'est pas si simple. Les indicateurs se trouvent à l'intérieur d'une autre entité, le graphique/la carte, et lui sont subordonnés (je suis conscient de leur relation complexe de type "un à plusieurs", mais cela ne change rien à l'affaire). Un graphique a son propre cycle de vie, qui comprend une sorte d'événements internes d'init et de deinit, qui constituent les limites du cycle de vie des indicateurs. En d'autres termes, un indicateur ne peut pas survivre à son graphique. Le désinit du graphique doit attendre le désinit ou le timeout du désinit de tous les indicateurs. Ce n'est qu'alors que l'init graphique pour le nouveau cadre temporel peut être lancé, et à partir de celui-ci les inits des indicateurs attachés peuvent être appelés.
Les graphiques sont les mêmes que les indicateurs. Les indicateurs peuvent "survivre" à leurs graphiques.
Avant le OnInit d'un indicateur/conseiller, les constructeurs des objets globaux sont exécutés. Après OnDeinit - les destructeurs. Par conséquent, vous pouvez supprimer OnInit et OnDeinit de tout indicateur.
Le seul problème est que vos idées sur les indicateurs ne correspondent pas à la réalité. Ce comportement est peut-être critique pour certains freelances qui ne peuvent pas écrire la solution.
Je serais heureux que les développeurs fassent un pas en avant sur ce sujet. Mais il y a deux points de vue tout à fait compréhensibles qui s'affrontent ici avec leur propre logique, comme il se doit. Aucun des deux n'est plus imparfait que l'autre. C'est juste que certains pensent que c'est bien de cette façon et d'autres pensent que c'est bien de cette façon.
Imaginez la lenteur des graphiques si, avant de changer de TF, le terminal attendait le déchargement de tous les indicateurs de l'ancien TF et seulement ensuite construisait et initialisait le nouveau TF.
Dans quelles situations, en dehors du travail simple avec des objets graphiques (sans le nom de TF dans le nom), la séquence DeInit - Init est-elle importante ?
Imaginez la lenteur des graphiques si, avant de changer de TF, le terminal attendait le déchargement de tous les indicateurs de l'ancien TF et seulement ensuite construisait et initialisait le nouveau TF.
Dans quelles situations, en dehors du simple travail avec des objets graphiques (sans le nom de TF dans le nom), la séquence DeInit - Init est-elle importante ?
+
Encore une fois. Lorsque vous changez de cadre temporel ou de symbole dans le graphique, une nouvelle copie de l'indicateur est créée. Une nouvelle.
Pour la même raison que les parties calculées des indicateurs vivent dans les caches de l'historique. Chaque période de temps a son propre cache de barres. Quand vous changez de timeframe, disons EURUSD,M1 sur EURUSD,H1, à l'indicateur dans le cache M1 est envoyé l'événement Deinit avec la cause 3 (changement de graphique) et après un certain temps cet indicateur sera déchargé. Si soudainement cet indicateur n'a pas eu le temps de gérer la désinitialisation avec la raison 3, il sera désinitialisé avec la raison 1 (fermeture du graphique). Si le cache H1 n'existait pas à ce moment-là, il sera créé. Ensuite, la copie de l'indicateur NEW est chargée dans le cache H1, auquel l'événement Init est envoyé. La nouvelle copie de l'indicateur ne sait rien de la copie précédente, qui est sur le point de mourir. Toutes les variables de la nouvelle copie de l'indicateur sont propres, elles viennent de naître.
En cas de changement d'horizon temporel au sein d'un même symbole, l'ordre d'initialisation/désinitialisation est en principe prévisible. Téléchargez la dernière version 1580 - nous avons corrigé certaines choses, maintenant la suppression des indicateurs est effectuée dans le tout dernier tour, donc il ne devrait pas y avoir de désinitération prématurée. Mais si vous changez le symbole, vous obtenez une course inter-thread sous une forme pure, et vous ne pouvez pas prédire la séquence d'initialisation-désinitialisation sans ambiguïté. Puisque différents caractères sont traités dans différents fils
Par conséquent, un conseil pour la personne qui lance le sujet. Concentrez-vous sur la cause de la désinitialisation. Si c'est 3, alors il n'est pas nécessaire de renvoyer le schéma de couleurs au graphique.
Imaginez la lenteur des graphiques si, avant de changer de TF, le terminal attendait le déchargement de tous les indicateurs de l'ancien TF et seulement ensuite construisait et initialisait le nouveau TF.
Dans quelles situations, en dehors du travail simple avec des objets graphiques (sans le nom de TF dans le nom), la séquence DeInit - Init est-elle importante ?
Pourquoi seraient-ils lents ? A moins que l'indicateur ne soit mal rédigé. Pour un indicateur bien écrit, DeInit prend un temps assez court. De plus, la commutation TF n'est pas une opération aussi fréquente. Dans certains cas particulièrement graves (pour les indicateurs "erronés"), vous pouvez attendre une seconde ou deux avant de changer de TF.
Par conséquent, l'argument du freinage pendant la commutation TF est plus que douteux. En outre, lorsque nous passons à la TF qui n'a pas encore été construite, nous rencontrons également un retard assez appréciable. Et personne ne pleure sur les freins du terminal.