Séquence d'exécution de Init() et DeInit() - page 4
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
Dans Deinit, écrivez toutes les données dans les globales. Définir un des globaux comme un sémaphore viaGlobalVariableSetOnCondition.
Init write que si le sémaphore est dans l'état "data dumped" nous allons lire et travailler en mettant le sémaphore dans l'état "read all".
Si le sémaphore est "inintelligible", nous attendons simplement le sémaphore (soit par une boucle Sleep ou OnTimer).
S'il n'y a pas de sémaphore du tout, cela signifie que nous démarrons pour la première fois et que nous comptons tout et en même temps nous créons un sémaphore pour le changement non futur du TF.
Qu'est-ce qui est si compliqué dans une telle mise en œuvre ? Prescrire une fois avec une bibliothèque et c'est tout.
Si Sleep travaillait dans les indicateurs, ce serait plus facile. Le sommeil ne fonctionne pas dans les indicateurs.
Si l'on multiplie le nombre de petites personnes qui, chacune de leur côté, vont résoudre un problème commun, les heures de travail perdues dépassent souvent (à la limite, un nombre infini de fois ;-)) le temps nécessaire à toute variante d'édition dans le terminal lui-même. Même la présence d'une bibliothèque hypothétique ne garantit pas que tout le monde sera au courant de son existence et aura besoin de l'utiliser. En général, il n'est pas clair pourquoi faire et laisser un tel "râteau" ?
Il ne s'agit donc pas d'un râteau, mais d'un comportement logique lorsque la nouvelle copie de l'indicateur ne connaît pas l'ancienne. C'est logique !
Mais UN MILLIERS de personnes veulent une fonctionnalité supplémentaire pour que la copie sache ! Alors, qu'est-ce qui empêche ces unités d'écrire une solution une fois et de l'utiliser ?
Pourquoi faire semblant de se soucier des autres. Ceux qui en ont vraiment besoin chercheront d'abord une solution. Et s'ils ne le font pas, ils essaieront d'en écrire un. Une base de code centralisée sert précisément cet objectif.
Si Sleep travaillait dans les indicateurs, ce serait plus facile. Le sommeil ne fonctionne pas dans les indicateurs.
Il ne s'agit donc pas d'un râteau, mais d'un comportement logique lorsque la nouvelle copie de l'indicateur ne connaît pas l'ancienne. C'est logique !
Mais UN MILLIERS de personnes veulent une fonctionnalité supplémentaire pour que la copie sache ! Alors, qu'est-ce qui empêche ces unités d'écrire une solution une fois et de l'utiliser ?
Pourquoi faire semblant de se soucier des autres. Ceux qui en ont vraiment besoin chercheront d'abord une solution. Et s'ils ne le font pas, ils essaieront d'en écrire un. Une kodobase centralisée sert précisément cet objectif.
Non, ce n'est pas si simple. Les indicateurs se trouvent à l'intérieur d'une autre entité - un graphique/une carte - et lui sont subordonnés (je suis conscient de leur relation complexe de un à plusieurs, mais cela ne change pas l'essence). 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.
Un râteau est, par définition, quelque chose qui peut être piétiné. On a déjà marché dessus. Un bon logiciel n'autorise pas le rake en principe.
Il ne s'agit donc pas d'un râteau, mais d'un comportement logique lorsque la nouvelle copie de l'indicateur ne connaît pas l'ancienne. C'est logique !
Mais UN MILLIERS de personnes veulent une fonctionnalité supplémentaire pour que la copie sache ! Alors, qu'est-ce qui empêche ces unités d'écrire une solution une fois et de l'utiliser ?
Pourquoi faire semblant de se soucier des autres. Ceux qui en ont vraiment besoin chercheront d'abord une solution. Et s'ils ne le font pas, ils essaieront d'en écrire un. Une kodobase centralisée sert précisément le même objectif.
Comment se fait-il que vous ne sachiez pas quand vous changez de période et entrez à nouveau les paramètres d'entrée ?
Et alors Deinit finira son travail et gâchera tout. Les Init et Deinit ordinaires n'ont aucun sens si vous créez vos propres Init et Deinit personnalisés.
J'ai également rencontré ce problème. (
Je vousai déjà tout dit, mais je vais en rajouter.
La particularité de tous les programmes de TA est qu'ils fonctionnent sur la base d'événements. Les OnInit et OnDeinit fonctionnent de manière tout à fait logique et appropriée selon le modèle d'événement.
Mais il y a une nuance étrange dans le comportement des variables d'entrée : tous les indicateurs de base, y compris les terminaux internes et ceux qui sont inclus dans la livraison standard - chaque fois qu'ils sont lancés avec les mêmes paramètres d'entrée qui ont été appelés depuis le lancement précédent. C'est très pratique. Mais il n'y a rien de tel pour les indicateurs personnalisés et pour tous les Expert Advisors et scripts, y compris les indicateurs standards, ce qui est un inconvénient(souhait à MQ : ajouter le même comportement pour les variables d'entrée que pour les indicateurs standards).
Et ce qui concerne le travail avec Init et Deinit, alors, personnellement, je n'ai jamais posé sur les raisons de la désinitialisation des programmes quand on travaille avec des variables globales du programme, je construis toujours la logique sous l'idée spécifique du programme. Par exemple, il est très souvent nécessaire de sauvegarder les variables globales d'un programme après la désinitialisation d'un EA (les raisons peuvent être différentes, par exemple la même déconnexion provoque OnDeinit et le OnInit suivant), alors pourquoi devrais-je tout recalculer et créer de nouveaux poignées d'indicateurs, etc.
C'est pourquoi, comme je l'ai écrit avant et fxsaber, si vous avez besoin de sauvegarder les variables globales d'un programme dans certains cas - vous pouvez le faire dans les variables globales du terminal en utilisant les drapeaux appropriés.
Dans MQL tout n'est pas lisse, malheureusement, mais le travail de OnInit et Ondeinit est logique et compréhensible, donc c'est une perte de temps).
Comment ça, vous ne savez pas ? Quand vous changez de période, est-ce que vous réintroduisez les paramètres d'entrée ?
Mais le fonctionnement de OnInit et Ondeinit est logique et compréhensible, il n'y a donc pas besoin d'en faire tout un plat).
Veuillez expliquer la logique de la séquence de OnInit et OnDeinit dans l'indicateur lorsque vous changez de cadre temporel. Je vous en serais très reconnaissant. Et je pense que je ne suis pas le seul.
Veuillez expliquer la logique de la séquence des opérations OnInit et OnDeinit dans l'indicateur lorsque vous changez de période. Je vous en serais très reconnaissant. Et je pense que je ne suis pas le seul.
M. Slava l'a dit clairement.
Une copie de l'indicateur est créée et l'ancien est déchargé après un certain temps.
Si nous voulons sauvegarder les variables globales du programme, nous devons nous en occuper au préalable, au moment de l'appel à OnInit (les variables globales du terminal client conviennent bien à cet effet).
Et les tampons des indicateurs seront recalculés de toute façon, parce que les barres (chandeliers) ont changé, apparemment, c'est pourquoi cela se passe de cette façon (la copie sera lancée et l'instance précédente de l'indicateur sera terminée par le terminal).
Si le développeur de l'indicateur voit le problème dans le travail avec des objets graphiques, alors au début de l'indicateur il est nécessaire de lier les noms des objets graphiques au nom de TF, alors la nouvelle copie de l'indicateur créera de nouveaux objets, et la copie précédente de l'indicateur nettoiera les anciens.
Pas de problème du tout.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Séquence d'exécution de Init() et DeInit()
Slawa, 2017.04.07 15:31
Quel genre de logique est-ce qu'il perturbe ?
Lorsque vous changez de cadre temporel, une nouvelle copie de l'indicateur est créée, qui ne sait rien de la copie précédente. Pendant un certain temps (un temps très court), les deux copies de l'indicateur existent en parallèle. Ensuite, la copie précédente est déchargée.
Lire la documentation https://www.mql5.com/ru/docs/runtime/running
M. Slava l'a dit clairement.
Une copie de l'indicateur est créée et l'ancien est déchargé après un certain temps.
Si nous voulons sauvegarder les variables globales du programme, nous devons nous en occuper au préalable, au moment de l'appel à OnInit (les variables globales du terminal client conviennent bien à cet effet).
Et les tampons des indicateurs seront recalculés de toute façon, parce que les barres (chandeliers) ont changé, apparemment, c'est pourquoi cela se passe de cette façon (la copie sera lancée et l'instance précédente de l'indicateur sera terminée par le terminal).
Si le développeur de l'indicateur voit le problème dans le travail avec des objets graphiques, alors quand vous démarrez l'indicateur, vous devriez lier les noms des objets graphiques au nom de TF, alors la nouvelle copie de l'indicateur créera de nouveaux objets, et la copie précédente de l'indicateur nettoiera les anciens.
Il n'y a pas de problème.
Oui, c'est compréhensible. Je m'interrogeais sur la logique de la séquence d'exécution. Le fait est qu'une telle logique n'existe pas. Parfois, OnDeinit est exécuté en premier (comme il se doit selon la logique du commun des mortels), et parfois OnInit est exécuté en premier.
Je comprends que la réponse se trouve dans la remarque"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.