Séquence d'exécution de Init() et DeInit() - page 9
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
Merci pour le code, bien sûr. Mais les EAs vont bien dans tous les cas carlorsque je change de TF, ils ne réinitialisent pas les variables, alors que les indicateurs le font. Si vous voulez vraiment m'aider en me donnant des conseils, je vous prie de le relancer en moins de temps.
Nicholas, je suis tombé sur le sujet, même lorsque j'ai écrit le premier message. Et je n'ai pas trouvé de discussion sur le comportement d'un EA lorsque l'horizon temporel change. Oui - le sujet concerne principalement les indicateurs, alors que l'auteur a écrit dans son post"Un indicateur ou un Expert Advisorest écrit ".
J'ai donné un exemple que j'ai vérifié et qui fonctionne dans le cadre du conseiller expert. Mais vous - ensuite vous me reprochez mon inattention, ensuite vous m'envoyez relire le sujet, ensuite vous discutez - ce qui est raisonnable ou pas raisonnable. En outre, vous pouvez lire la première page
Il n'est pas clair si nous parlons d'un conseiller expert ou d'un indicateur. Vous ne dites même pas clairement dans votre message que vous parlez d'un indicateur.
VOIR UN EXEMPLE DE VOTRE POSTE :
Alors, c'est tout ?
J'ai expérimenté et utilisé au maximum ce code de raison (REASON_CHARTCHANGE). Mais à quoi bon si toutes les variables sont mises à leur état initial et que OnDeinit est exécuté après OnInit du nouveau TF ?
Est-il clair, d'après ce que je viens de dire, que les variables sont initialisées dans l'indicateur ?
La personne qui lit votre article peut penser que la même chose se produit dans un conseiller expert.
----
La réponse à cette question :"Lorsque vous changez de TF, la réinitialisation des variables ne se produit pas, alors qu'elle se produit dans les indicateurs".
vous pouvez enregistrer les valeurs des variables quelque part, dans les globales par exemple...
Si vous voulez utiliser cette fonction d'une autre manière, vous devez utiliser OnInit pour lire et restaurer les valeurs.
------------
Si vous n'êtes intéressé que par le problème du changement de la TF pour l'indicateur - cela ne signifie pas que d'autres, y compris moi, ne sont pas intéressés par l'option de changer la TF pour l'EA.
Je ne peux pasdonner de conseils sur l'indicateur, car je ne sais pas comment le faire en pratique, mais j'observerai avec intérêt les solutions proposées.
J'ai cru comprendre que les développeurs lisent ce sujet et ont même corrigé certaines choses dans la build 1580. Peut-être proposeront-ils des solutions.
N'avez-vous pas lu plusieurs fois ce que j'ai écrit ?
Il n'y a aucun moyen dans les indicateurs. Vous ne pouvez pas le faire en cinq dès le début. Parce que vous devez télécharger une toute nouvelle copie de l'indicateur avec toutes ses conséquences.
Merci pour votre réponse honnête.
Cela a toujours été comme ça dans le 5. Il est peut-être temps de le réparer ?
Est-ce vraiment si difficile de faire le bon ordre ? Le gain de temps au départ se traduit ensuite par des contrôles interminables à chaque tic.
Je me suis déjà habitué au paradigme OOP de MT5 et je sais où se trouve le râteau et comment fixer des béquilles pour contourner ces râteaux, bien sûr s'il n'y en a pas de nouveaux. Il s'avère qu'il est plus facile de supprimer un objet et d'en créer un nouveau que de modifier quelques paramètres.
De même, dans une voiture, au lieu de changer l'huile et de continuer à rouler, il est préférable de jeter la voiture et d'en fabriquer une nouvelle.
Ça me rappelle un dessin animé :
Pouvez-vous me le dire ?
J'ai décidé d'écrire un programme qui
1. 8 lignes de sortie sur place
2. sur DeInite sort 8 lignes supplémentaires.
Je l'ai fait tourner dans le testeur (je l'ai fait tourner pendant 2 jours et je l'ai eu).
Pour une raison quelconque, il ne parvient pas à enregistrer certaines chaînes de manière sélective.
Est-ce que c'est aussi pour accélérer les choses???
------------------------------------------------------------------------------------------
QUESTION RÉSOLUE PARCE QUE LES JOURNAUX COMPLETS CONTIENNENT TOUTES LES INFORMATIONS
------------------------------------------------------------------------------------------
Dans la documentation, il est nécessaire d'ajouter
1. Le journal n'affiche pas toutes les informations attendues par le programmeur.
-------- IL EST INDISPENSABLE DE VOIR LE JOURNAL COMPLET ! !!
Je voudrais résumer et résumer ce qui précède. Donc, avant la sortie de la version 1580 de MT5 (version actuelle 1571), qu'avons-nous ?
Dans les indicateurs, contrairement aux Expert Advisors, quand le TF change, parce que"une nouvelle copie de l'indicateur est créée, qui ne sait rien de la copie précédente", toutes les variables sont réinitialisées, en plus l'ordre d'exécution de OnDeinit de l'ancien TF et OnInit du nouveau TF est imprévisible, indépendamment du fait que le TF soit "up" ou "down" (pratique, contrairement à ce qui a été mentionné par M. Slava). Dans ce contexte, les programmateurs sont confrontés à un certain nombre de problèmes et d'incertitudes. Par exemple :
- le programmeur, qui n'a pas lu ce sujet, crée un objet pour quelque chose dans OnInit, vérifiant logiquement avant la création de l'indicateur l'existence d'un objet avec ce nom. Il est également logique de prescrire la suppression de cet objet dans OnDeinit. Lorsque le TF est modifié, si le premier OnInit du nouveau TF est exécuté, il vérifie l'existence de l'objet, il s'avère qu'il existe déjà, et il n'est pas créé, car il est déjà créé. Ensuite, le OnDeinit de l'ancien TF est effectué et l'objet est supprimé. Le programmeur est en état de choc. Où est mon objet et pourquoi a-t-il disparu ? Il sera encore plus confus, lorsque la prochaine fois que le TF est modifié, lorsque la séquence de OnInit et OnDeinit est différente, l'objet n'est pas supprimé. C'est supprimé, ce n'est pas supprimé.... Après une longue recherche, vous commencerez à adresser au Service Desk, de nouveaux fils de discussion sur le forum à propos de l'ancien.
Ce n'est que la situation la plus simple. Il y en aura d'autres car cette fonctionnalité n'est pas décrite dans la documentation et vous ne pouvez en prendre connaissance que sur le forum.
Si vous voulez créer quelque chose de spécial et passer certains paramètres de l'ancienne copie de l'indicateur à la nouvelle, lorsque vous changez le TF, vous ne pouvez pas utiliser OnDeinit à cause de la séquence imprévisible des opérations d'initialisation et de désinitialisation. A monavis, la meilleure solution dans ce cas est d'utiliser les outils suivants :ResourceCreate basé sur le tableau de pixels etResourceReadImage, mais c'est assez lourd et vous devez faire attention aux conflits de ressources, si vous utilisez plusieurs indicateurs identiques dans une fenêtre, et chaque fois que les données que vous voulez envoyer pour une autre copie doivent être sauvegardées dans une ressource non réinitialisée, parce que le moment du changement possible de TF n'est pas connu pour l'application. Je l'ai mis en œuvre il y a longtemps (par exemple dans ce produit), je sais donc de quoi je parle. La mise en œuvre du transfert de données par le biais de fichiers et de variables globales du terminal est une solution moins efficace (IMHO).
Si la nouvelle build 1580 seracomme le dit Slava, cela ne facilitera pas la tâche, car la désinitialisation de l'ancienne copie de l'indicateur sera effectuée après l'initialisation d'une nouvelle copie. Mais il n'y aura pas d'incertitude.
J'espère que les développeurs ont prêté attention à ce problème puisqu'ils essaient de corriger quelque chose.
Nous attendons la nouvelle construction.
Tous les objets du graphique sont nommés en référence à la TF actuelle. Lors de l'initialisation, créer, lors de la désinitialisation, supprimer. Pendant l'exploitation de l'indicateur, nous apportons les modifications nécessaires.
Y a-t-il un problème ici ? Pas de problème. Tout est normal depuis le moment du démarrage de l'indicateur jusqu'au moment de son déchargement.
On change la TF. Peu importe dans quel sens il va, vers le haut ou vers le bas. Une copie de l'indicateur est lancée. Cela correspond au fait que l'indicateur a été lancé pour la première fois sur ce TF.
Y a-t-il un problème ici ? Il n'y a pas de problème. L'ancienne copie se chargera de supprimer ses objets, et la nouvelle copie en créera de nouveaux en fonction du calendrier actuel.
Qu'est-ce que je fais de mal ? Pourquoi je ne vois pas de problème ?
Tous les objets du graphique sont nommés en référence à la TF actuelle. A l'initialisation, nous créons, à la désinitialisation, nous supprimons. Pendant le fonctionnement de l'indicateur, modifier si nécessaire.
Y a-t-il un problème ici ? Pas de problème. Tout est normal depuis le moment du démarrage de l'indicateur jusqu'au moment de son déchargement.
On change la TF. Peu importe dans quel sens il va, vers le haut ou vers le bas. Une copie de l'indicateur est lancée. Cela correspond au fait que l'indicateur a été lancé pour la première fois sur ce TF.
Y a-t-il un problème ici ? Il n'y a pas de problème. L'ancienne copie se chargera de supprimer ses objets, et la nouvelle copie en créera de nouveaux en fonction du calendrier actuel.
Qu'est-ce que je fais de mal ? Pourquoi je ne vois pas de problème ?
Aucun problème si vous êtes conscient de cette fonctionnalité non documentée et que vous ne traitez que le cas le plus simple - avec le graphique. objets. Je veux dire ceux qui ne connaissent pas cette fonctionnalité, je pense que ce sujet est lu par un très petit pourcentage de programmeurs sur ce forum, et je plains leur temps pour comprendre toutes les nuances. J'avais été dans cette situation avant d'en comprendre l'essence.
Je n'ai jamais entendu parler de nuances telles que celles décrites dans ce fil, mais je n'ai jamais rencontré de problèmes tels que ceux décrits ici.
si vous voulez transférer quelque chose à une autre copie de l'indicateur, vous n'avez pas besoin de le faire deinit - gardez les données transférées à jour pendant toute la durée de vie de l'indicateur - par exemple dans les variables principales du terminal, puis quelle que soit la raison du déchargement de l'indicateur (changement de TF, maman a débranché la prise "pour qu'il ne ronfle pas quand tout le monde dort", tremblement de terre, changement des pôles magnétiques de la terre et ainsi de suite.etc.), la prochaine exécution de l'indicateur (y compris une copie lorsque le TF change) obtiendra toutes les informations nécessaires de cette source de données magique (pour les cas malchanceux d'échelle mondiale, vous pouvez conserver les données sur un disque en nuage).
Les gars, il n'y a pas de problème du tout.
Tous les objets du graphique sont nommés en référence à la TF actuelle. À l'initialisation, nous créons, à la désinitialisation, nous supprimons. Pendant le fonctionnement de l'indicateur, modifier si nécessaire.
Y a-t-il un problème ici ? Pas de problème. Tout est normal depuis le moment du démarrage de l'indicateur jusqu'au moment de son déchargement.
On change la TF. Peu importe dans quel sens il va, vers le haut ou vers le bas. Une copie de l'indicateur est lancée. Cela correspond au fait que l'indicateur a été lancé pour la première fois sur ce TF.
Y a-t-il un problème ici ? Il n'y a pas de problème.
Il y a un problème : l'existence simultanée d'objets de différents indicateurs. "Désolé, nous avons des problèmes techniques temporaires" (mais cela sera résolu dans quelques secondes quand le DeInit de l'ancien indicateur se produira)
L'ancienne copie se chargera de supprimer ses objets, et la nouvelle copie créera ses nouveaux objets, en les nommant en fonction de la TF actuelle.
Qu'est-ce que je fais de mal ? Pourquoi je ne vois aucun problème ?
C'est une vision étroite. C'est pour ça que tu ne peux pas voir. Élargissez un peu vos horizons. Les premiers problèmes surviennent lors du travail avec les fichiers, car on ne sait pas si l'indicateur précédent a déjà réussi à enregistrer des données dans le fichier ou pas encore. Certains drapeaux dans les variables globales du terminal devront être créés. La nouvelle copie de l'indicateur devra attendre que l'ancienne copie remette à zéro les données accumulées. Au fait, le problème est que cette synchronisation n'est possible que dans OnCalculate(). Et que faire si l'échange a eu lieu le week-end ? Une nouvelle copie ne commencera pas avant lundi ? Oh, oui, on peut le mettre sur une minuterie ! J'ai entendu dire qu'on pouvait tirer sur les moineaux avec un canon, la fronde serait une bonne solution.
Ce sont encore des problèmes simples. Essayez de tenir compte de cette logique lorsque vous travaillez avec des DLL multithreads. Maintenant, c'est là que le plaisir commence. Eh bien, nous allons devenir plus forts ))))
Je n'ai jamais entendu parler de nuances telles que celles décrites dans ce fil, mais je n'ai jamais rencontré de problèmes tels que ceux décrits ici.
si vous voulez transférer quelque chose à une autre copie de l'indicateur, vous n'avez pas besoin de le faire deinit - gardez les données transférées à jour pendant toute la durée de vie de l'indicateur - par exemple dans les variables principales du terminal, puis quelle que soit la raison du déchargement de l'indicateur (changement de TF, maman a débranché la prise "pour qu'il ne ronfle pas quand tout le monde dort", tremblement de terre, changement des pôles magnétiques de la terre et ainsi de suite.etc.), le prochain lancement de l'indicateur (y compris la copie au changement de TF) obtiendra toutes les informations nécessaires de cette source de données magique (pour les cas malchanceux d'échelle mondiale, il est possible de conserver les données sur un disque en nuage).
Les gars, il n'y a pas de problème du tout.
Il y a un problème : l'existence simultanée d'objets de différents indicateurs. "Désolé, nous avons des problèmes techniques temporaires" (mais ils seront résolus dans quelques secondes, lorsque l'ancien indicateur sera désinstallé).
Un champ de vision étroit. C'est pour ça que tu ne peux pas voir. Élargissez un peu vos horizons. Les premiers problèmes apparaissent lorsque l'on travaille avec des fichiers, car on ne sait pas si l'indicateur précédent a déjà réinitialisé les données dans le fichier ou pas encore. Certains drapeaux dans les variables globales du terminal devront être créés. La nouvelle copie de l'indicateur devra attendre que l'ancienne copie remette à zéro les données accumulées. Au fait, le problème est que cette synchronisation n'est possible que dans OnCalculate(). Et que faire si l'échange a eu lieu le week-end ? Une nouvelle copie ne commencera pas avant lundi ? Oh, oui, on peut le mettre sur une minuterie ! J'ai entendu dire qu'on pouvait tirer sur les moineaux avec un canon, la fronde serait une bonne solution.
Ce sont encore des problèmes simples. Essayez de tenir compte de cette logique lorsque vous travaillez avec des DLL multithreads. Maintenant, c'est là que le plaisir commence. Eh bien, nous deviendrons plus forts))))
Je l'ai écrit très clairement : gardez toujours à jour les données dont vous avez besoin pour la copie. Vous ne devez pas le faire uniquement lorsque vous les utilisez, vous devez toujours les garder à jour.
Tous les autres cas sont inventés à cause de la mauvaise humeur.
S'il y a un problème pour exécuter le même indicateur en même temps, alors créez des objets uniques à chaque fois avec un lien vers le TF et s'il y a déjà des objets, ajoutez 1 au nom.
Personne n'a cité un seul cas où les problèmes sont insurmontables en raison de la manière dont le terminal fonctionne actuellement avec les indicateurs. Les problèmes sont causés par un travail incorrect avec les indicateurs.
En général, beaucoup de gens ne semblent pas comprendre qu'il existe 3 types de programmes pour une raison précise (le 4ème sera bientôt disponible).