Séquence d'exécution de Init() et DeInit() - page 3
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
Essayez de mettre à jour le terminal à la version 1065. Les versions précédentes avaient une erreur de réinitialisation juste en changeant le délai. Cela pourrait aider :)
https://www.mql5.com/ru/forum/187690
J'ai le terminal 5.00 b1571
Vous pouvez enregistrer les valeurs des variables quelque part, dans des globales par exemple. Après les avoir traduites, vous pouvez lire et restaurer les variables.
Et alors Deinit finira son travail et gâchera tout. Il n'y a aucun sens à utiliser des Init et Deinit réguliers si vous faites vos propres Init et Deinit personnalisés.
J'ai également rencontré ce problème. (
Et alors Deinit finira son travail et ruinera 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 suis tout à fait d'accord (il n'y a aucun sens à utiliser régulièrement Init et Deinit).
Essayez peut-être d'attribuer aux objets graphiques une période TF dans le cadre du préfixe de leur nom,
et ensuite appliquer quelque chose comme ça :
Oui, j'ai dû faire quelque chose comme ça, mais c'est une solution partielle.
Vous pouvez faire de même avec les variables par le biais d'une ressource ou de fichiers, mais il s'agit d'une ressource supplémentaire distincte, qui aurait pu être évitée en corrigeant MT5.
Encombrer le code avec des fonctions annexes supplémentaires, des contrôles, etc. (SANS....)
J'ai toujours pensé (en vain), que lorsque je change de TF, je désinitais d'abord sur l'ancienne TF et ensuite Init sur la nouvelle. Il s'agit d'un déroulement logique des événements, sur lequel je me suis appuyé pour développer des conseillers experts et des indicateurs. Et voilà qu'il s'agit d'un véritable non-sens avec des événements qui interrompent la séquence des événements...
J'ai parfois remarqué, en travaillant avec des diagrammes et des objets graphiques, que quelque chose n'allait pas et j'ai dû changer de TF plusieurs fois pour voir que tout s'affichait correctement.
Maintenant je dois regarder dans les codes, où dans les déinites quelque chose change et ensuite les inites changent aussi en retour... et il s'avère que la séquence est l'inverse ! !! C'est juste une logique affreuse. Qui a eu cette idée ?
La première chose qui me vient à l'esprit est que dans mon deinit, l'état précédent (boutons enfoncés/relâchés) est stocké dans les variables globales, puis les boutons sont définis en fonction des valeurs enregistrées dans les inits. Et ce sont les boutons qui ne se remettent pas toujours à zéro correctement. C'est la première chose dont je me suis souvenu, je vais peut-être trouver autre chose... Je vais creuser demain.
Merci aux développeurs, ils ont mis beaucoup de travail...
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.
Dans Deinit, écrivez toutes les données dans les globales. Définir un des globaux comme un sémaphore viaGlobalVariableSetOnCondition.
Dans Init write, si l'état du sémaphore est "data dumped", il faut lire et travailler en mettant le sémaphore sur "read all".
Si le sémaphore est "illisible", nous attendons simplement que le sémaphore revienne (soit via les boucles Sleep ou OnTimer).
Qu'est-ce qui est si compliqué dans une telle mise en œuvre ? L'écrire une fois dans la bibliothèque et c'est tout.
Je ne savais pas du tout qu'il y avait un tel problème. J'espérais une séquence deiniti-init et non l'inverse. Quand on connaît les problèmes, on peut les résoudre. Mais il me semble qu'il devrait être résolu au niveau de la logique terminale et non avec des béquilles, qui devraient être insérées dans chaque programme maintenant...
Il ne s'agit pas d'une béquille, mais d'une solution simple. La seule question est de savoir qui la met en œuvre - les développeurs ou les utilisateurs. Dans les deux cas, il faut y consacrer du temps et l'écrire une fois. Si les utilisateurs peuvent le faire, nous l'avons écrit et nous ne prenons plus la peine de discuter de la question. Je viens de lire le fil de discussion moi-même et une solution m'est venue à l'esprit immédiatement. Qu'est-ce qu'il y a à décortiquer ? Vous pouvez exiger quelque chose pendant longtemps, ou vous pouvez l'écrire vous-même rapidement.