Séquence d'exécution de Init() et DeInit() - page 19
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
Pas de solution signifie "ne sait pas encore comment résoudre", et non "ne le fera pas".
Et avec les événements d'utilisateurs, il n'y a pas de problème du tout.
En quoi les services ou la possibilité d'exécuter plusieurs EA sur un seul graphique ne couvrent-ils pas entièrement les problèmes évoqués ?
C'est aux personnes qui se noient de les sauver.
Je suggère de supprimer tout ce qui se trouve à partir du post 125, car cela n'est pas pertinent pour une discussion constructive sur les priorités deinit et init lors d'un changement de TF.
Un indicateur a une première initiale puis une désinitiale. Mais lorsque l'on change de cadre temporel, la deuxième instance d'indicateur est créée, et son init peut être exécuté plus tôt que le deinit de l'instance précédente (non explorée).
L'exemple le plus évident - la sauvegarde des paramètres utilisateur lors du changement de période - nous sauvegardons les paramètres dans le deinit, nous les lisons dans le init. Si le init de la nouvelle instance est déclenché avant le deinit de l'instance précédente, les paramètres ne seront pas sauvegardés.
En pratique, le deinit de l'instance supprimée se déclenche la plupart du temps avant le init de la nouvelle instance, mais si le changement d'horizon temporel est très rapide ou si les données sont chargées, alors un échec se produit.
Dimitri, lorsque vous conduisez une voiture, devez-vous regarder dans le rétroviseur lorsque vous êtes déjà arrivé ? Ou devez-vous sauvegarder périodiquement les paramètres requis dans l'indicateur. C'est comme regarder dans le rétroviseur.
Vous pouvez, bien sûr, continuer à vous plaindre que la pierre ne contribue pas au sauvetage d'un homme qui se noie lorsqu'on lui lance une bouée de sauvetage.
Le râteau reste. C'est l'essentiel. (dans cette analogie, un tour de piste est distribué sur demande dans un chantier naval, et les gens se noient au hasard et de manière inattendue).
Si les anciennes puces ne sont pas en bon état, les nouvelles le seront aussi. L'approche ne change pas.
En somme, j'ai tout dit, à mon avis, plus que raisonnablement et logiquement. Si quelqu'un est dans le réservoir, je ne peux pas aider.
Si les anciennes fonctionnalités ne sont pas bonnes, les nouvelles le seront aussi. L'approche ne change pas.
En d'autres termes, l'ordre d'exécution des OnInit et OnDeinit de l'indicateur lors du changement de la période-symboledu graphique ne devrait gêner personne.
OnInit démarre la minuterie, onDeinit la supprime. En raison d'une mauvaise file d'attente, personne ne sait quoi.
Bug désagréable, qui est ignoré de manière flagrante par les développeurs.
Init démarre le timer, in deinit le supprime. En raison de la mauvaise file d'attente, on ne sait pas ce qui se passe.
Un méchant bug ignoré de manière flagrante par les développeurs.
L'ordre est sans ambiguïté.
Quand vous changez lef.
Si les indicateurs ont encore des déchets dans les tampons de l'ancien TF, peut-être que les timers seront également affectés.