Séquence d'exécution de Init() et DeInit() - page 6
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
Pourquoi seraient-ils lents ? A moins que l'indicateur ne soit mal écrit. Un indicateur DeInit bien écrit prend assez peu de temps. 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.
Il existe différents indicateurs. Il y en a aussi qui sont lents. Et toutes ne sont pas propres et en code source.
Je m'amuse pendant quelques secondes. Je ressens des dizaines de millisecondes dans l'interface, je ressens un inconfort immédiat.
Et, surtout, il n'y a pas de réponse à ma question :
Dans quelles situations, à l'exception du travail simple avec des objets graphiques (sans nom TF dans le titre), la séquence DeInit - Init est-elle importante ?
Les indicateurs sont de toutes formes et de toutes tailles. Ceux qui sont freinés aussi. Et toutes ne sont pas propres et en code source.
Quelques secondes, c'est drôle. On sent des dizaines de millisecondes dans l'interface, il y a un inconfort immédiat.
Et, plus important encore, il n'y a pas de réponse à ma question :
Dans quelles situations, autres que le travail simple avec des objets graphiques (sans nom TF dans le nom), la séquence DeInit - Init est-elle importante ?
Je n'utilise généralement pas de variables globales, mais cela arrive parfois.
Lorsque l'on travaille avec des variables globales, on se retrouve dans le désordre. Lorsque vous supprimez l'indicateur du graphique, vous devez faire le ménage après vous et supprimer les variables globales. A quel endroit de l'indicateur supprimez-vous les variables globales ? Probablement, il devrait être supprimé dans Deinite, il n'y a pas d'autre endroit. Ainsi, lorsque vous changez d'horizon temporel et créez de nouvelles variables, Deinite vient tout effacer. Il s'avère que les variables globales ne peuvent pas être utilisées dans les indicateurs.
Je n'utilise généralement pas de variables globales, mais cela arrive parfois.
Lorsque l'on travaille avec des variables globales, on se retrouve en difficulté. Lorsque vous supprimez l'indicateur du graphique, vous devez faire le ménage après vous et supprimer les variables globales. A quel endroit de l'indicateur allez-vous supprimer les variables globales ? Probablement, il devrait être supprimé dans Deinite, il n'y a pas d'autre endroit. Ainsi, lorsque vous changez d'horizon temporel et créez de nouvelles variables, Deinite vient tout effacer. Il s'avère que les variables globales ne peuvent pas être utilisées dans les indicateurs.
Sergiy, avez-vous un exemple réel qui ne soit pas sorti de nulle part ? Je peux aussi penser à un tel exemple, mais je n'ai pas rencontré de problèmes dans la pratique.
Remarque : Les variables globales peuvent également être nommées en fonction de TF.
Les indicateurs sont de toutes formes et de toutes tailles. Ceux qui sont freinés aussi. Et toutes ne sont pas propres et en code source.
Quelques secondes, c'est drôle. L'interface se ressent en quelques dizaines de millisecondes, le malaise apparaît immédiatement.
Et, plus important encore, il n'y a pas de réponse à ma question :
Dans quelles situations, en dehors du travail simple avec des objets graphiques (sans nom de TF dans le titre), la séquence DeInit - Init est-elle importante ?
J'ai donné un exemple concret à la page 3 :
mémoriser dans la tête du terminal à chaque fois que les variables pertinentes sont modifiées, et non lors des ini/deinit.
se souvenir dans le terminal principal à chaque fois que les variables correspondantes sont modifiées, et non lors des ini/deinit.
Je m'en souviendrai)
Et n'oubliez pas non plus que dans l'implémentation actuelle, rien ne peut être fait dans Deinit qui doit ensuite être utilisé (ni dans les variables globales, ni dans l'écriture dans les fichiers)...
le finci est devenu essentiellement inutile, avec une telle séquence brisée.
Je m'en souviendrai (c'est bien que je sois tombé sur ce fil de discussion par accident), mais d'autres programmeurs (qui ne regarderont pas ici) utiliseront la conséquence logique naturelle et utiliseront Deinit en espérant que cela fonctionnera, et ensuite init sera exécuté sur un nouveau TF.
Je m'en souviendrai)
Rappelez-vous également que l'implémentation actuelle du terminal ne permet pas de faire quoi que ce soit dans Deinit qui devrait être utilisé plus tard (ni dans les variables globales, ni dans les fichiers)...
essentiellement un finkzi inutile, avec une telle séquence brisée
Comprenez qu'il existe aussi une autre logique. La logique des développeurs MT en particulier. Selon cette autre logique, tout semble logique. D'où la conclusion : adaptez-vous à cette logique et n'essayez pas de faire changer d'avis des personnes qui sont probablement plus expérimentées que vous en la matière. C'est inutile... Personne n'acceptera de changer la logique établie pour le bien d'un indicateur.
S'il ne s'agissait pas de finances, il n'y aurait peut-être pas eu une telle discussion.
Et comme un conseiller en trading dépend d'un indicateur ou d'un autre, il cessera tout simplement de fonctionner correctement à cause d'un simple changement de TF. C'est ce qui est le plus stressant.
Alors comment pouvez-vous lui faire confiance avec vos finances ?
Nous sommes peut-être en désaccord avec les développeurs de MT sur cette question.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 ?
Vous confondez tous beaucoup de choses différentes. Mettons-nous d'accord sur au moins deux exigences pour le terminal en tant que logiciel critique :
- il doit fonctionner de manière prévisible, en suivant strictement la même logique (même avec le multithreading) ;
- il doit fonctionner rapidement.
(il n'est pas important de savoir si la copie de l'indicateur connaît d'autres copies, mais il est important que les données globales, attribuées pour le stockage au terminal, soient cohérentes - ceci est la préoccupation du terminal, pas de chaque développeur d'indicateur)
Il reste à savoir comment le mettre en œuvre. Il est maintenant mis en œuvre en tenant compte de l'exigence 2. Je propose de le mettre en œuvre en considérant l'exigence 1, sans affecter l'exigence 2.
Il n'y aura pas de ralentissements notables, si nous faisons attention au fait que les événements d'init/deinit du graphique et d'init/deinit de l'indicateur sont des choses différentes. Le graphique affichera immédiatement le nouveau graphique principal, mais pour les anciens indicateurs, l'événement OnInit sera mis en file d'attente après le traitement du précédent OnDeinit. Les événements sont de toute façon mis en file d'attente dans le terminal.
Si MQ le souhaite, peut m'envoyer sur ses termes des tableaux NDA de classes et de séquences, je les corrigerai ;-).