Séquence d'exécution de Init() et DeInit() - page 11
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
N'est-ce pas une honte de perdre son temps à des querelles inutiles sur des sujets aussi insignifiants ?
En fait, il est même plus important d'être simplement conscient de cette particularité.
J'ai clairement écrit - gardez toujours à jour les données à transférer sur la copie, vous ne devez pas le faire seulement lors de l'ouverture, gardez-les toujours à jour.
Où ces données doivent-elles être mises à jour ? Un exemple, s'il vous plaît. Je ne pense pas que vous puissiez faire mieux qu'un dossier. Donc, juste avec le fichier est un énorme problème. Ou pensez-vous que la mise à jour d'un fichier toutes les secondes est une excellente pratique ?
Tous les autres cas sont inventés à cause de la mauvaise humeur.
Donc, la "perturbation temporaire sur les écrans bleus" est aussi la faute de celui qui écrit l'indicateur ? C'est exactement l'exemple que personne n'a encore dit comment contourner. Et il n'y a aucun moyen de contourner ce problème.
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. Ces problèmes sont dus à une mauvaise manipulation des indicateurs.
J'ai déjà donné plusieurs exemples. Mais vous les écartez tout simplement, ou en d'autres termes, vous fermez les yeux sur les problèmes.
En général, beaucoup de gens ne semblent pas comprendre qu'il y a 3 types de programmes pour une raison (le 4ème viendra bientôt).
Oui, pour une raison. En raison d'une faiblesse humaine élémentaire - s'arrêter à mi-chemin. Il doit y avoir 1 type de programme dans une plateforme. Ni plus ni moins. L'apparition du 4ème type est un approfondissement de l'autodestruction.Avec ce genre d'attitude envers les développeurs, il est étrange de vous entendre attendre des développeurs qu'ils résolvent votre problème.
Et si même moi, qui suis un ardent défenseur de toutes sortes d'améliorations et de simplifications pour la plate-forme, je n'y vois pas de problème, les personnes qui aiment s'arrêter à mi-chemin n'y verront pas non plus de problème.
N'est-ce pas dommage de perdre son temps à des chamailleries inutiles sur des sujets aussi futiles ?
Avec ce genre d'attitude envers les développeurs, il est étrange d'entendre de votre part que vous attendez des développeurs qu'ils résolvent votre problème.
J'ai une attitude normale envers les développeurs de plates-formes ;)) La faiblesse humaine est notre problème commun, et non le problème de ses représentants individuels.
Bien que vous et moi ayons vraiment divergé sur le sujet des types de programmes. Vous devriez avoir un fil séparé pour cela. Mais je n'y vois pas beaucoup de sens, car il s'agira d'une démarche purement académique sans la moindre application pratique.
Le sens de ce dont je parle est la logique habituelle de l'exécution d'un programme. Cette logique était dans MT4, et il faut la transférer à MT5. En fait, ce n'est pas un inconvénient de MT4. Dans ce cas, c'est son avantage par rapport à MT5. Donc, si vous voulez développer MT5 et oublier rapidement MT4, pourquoi ne pas prendre le meilleur de MT4 ? Eh bien, nous devons corriger les défauts et, tout au plus, améliorer les avantages. Mais pour introduire de nouveaux inconvénients...
Alors c'est tout ?
J'ai expérimenté et utilisé ce code de raison (REASON_CHARTCHANGE) dans toute sa mesure. Quelle est l'utilité si toutes les variables sont remises dans leur état d'origine et que OnDeinit peut être exécuté après OnInit de la nouvelle TF ?
Raisons de la désinitialisation
Codes de raison de désinitialisation d'Expert Advisor retournés par UninitializeReason(). Peut avoir l'une des valeurs suivantes :
.........
Lesindicateurs n'acceptent pour l'instant que le code 1(REASON_REMOVE) et le code 2(REASON_RECOMPILE).
Raisons de la désinitialisation
Codes de raison de désinitialisation d'Expert Advisor retournés par UninitializeReason(). Peut avoir l'une des valeurs suivantes :
.........
Lesindicateurs n'acceptent pour l'instant que le code 1(REASON_REMOVE) et le code 2(REASON_RECOMPILE).
Raisons de la désinitialisation
Codes de raison de désinitialisation d'Expert Advisor retournés par UninitializeReason(). Peut avoir l'une des valeurs suivantes :
.........
Lesindicateurs n'acceptent pour l'instant que le code 1(REASON_REMOVE) et le code 2(REASON_RECOMPILE).
Cette information est obsolète. Après de nombreuses demandes, nous avons commencé à envoyer d'autres raisons aux indicateurs.
Il y a eu beaucoup de discussions aussi. Il est étrange que personne ne se soit souvenu des différentes copies des indicateurs.
J'ai une attitude normale envers les développeurs de plates-formes ;)) La fragilité humaine est notre problème commun, et non le problème de ses représentants individuels.
Bien que vous et moi nous soyons effectivement éloignés du sujet des types de programmes. Nous aurions dû créer une branche séparée pour cela. Mais je n'y vois pas beaucoup de sens, parce que ce sera purement académique, sans même un soupçon de mise en œuvre pratique.
Lesens de ce dont je parle est la logique habituelle de l'exécution d'un programme. Cette logique existait dans MT4, et elle doit être transférée dans MT5. En fait, ce n'est pas un inconvénient de MT4. Dans ce cas, c'est son avantage par rapport à MT5. Donc, si vous voulez développer MT5 et oublier rapidement MT4, pourquoi ne pas prendre le meilleur de MT4 ? Eh bien, nous devons corriger les défauts et, tout au plus, améliorer les avantages. Mais pour introduire de nouveaux inconvénients...
C'est ça, on se plaint...
Vous demandez exactement ce qui n'est pas disponible dans les applications de bureau normales. Si les développeurs ne faisaient pas toutes ces fonctionnalités qui sont déjà "prêtes à l'emploi", les auteurs de programmes MQL seraient constamment confrontés à tous les charmes du développement de bureau, qu'il s'agisse de problèmes de sécurité ou de vitesse d'exécution.Question très discutable sur rien de compliqué. Essayez vraiment de répéter par l'exemple d'une simple montre-bracelet ce que j'ai mis en œuvre dans ce produit. Dans le bracelet, vous modifiez la période avec votre souris et, lorsque vous changez de TF, les modifications doivent être enregistrées. Et vous verrez qu'il n'y a rien de compliqué. Et si vous avez besoin de passer un tableau. Et vous verrez comme c'est "simple". Je le penserais peut-être moi-même, si je ne l'ai pas déjà mis en œuvre.
Quel est le problème de stocker la période dans une variable principale ?
Pourquoi serait-il nécessaire de transférer un tableau de données entre des exécutions successives de l'indicateur sur des TF différentes ?