Mt4 Fin de l'assistance. - page 40
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
Donc, vous voulez que je continue à dénigrer les avantages de la POO, et que tout le monde continue à me troller). Mais en substance, vous avez raison. La discussion est partie dans la mauvaise direction.
Mais je ne suis pas un troll. Ne répondez pas aux trolls.
Dans le TWS, les barres sont formées par le temps, indépendamment de l'arrivée d'une cotation. S'il n'y a pas de cotation et qu'il est temps pour une nouvelle barre, la barre apparaît comme un tiret sur le prix de la dernière cotation. Dans ce cas, tous les indicateurs sont dessinés de la même manière que dans MT. Toutes mes idées sur les bars viennent de l'expérience de travail avec les TS.
Si c'était la même chose à MT, ma solution serait la plus efficace. Cependant, il n'est pas...
Par conséquent, je ne suggérerai plus de l'utiliser.
Peter, je propose un autre sujet de discussion, pour la deuxième fois. Pas besoin d'écrire quoi que ce soit, juste de la théorie.
Mais je ne suis pas un troll. Les trolls ne répondent pas.
Je vois. Il se peut donc que la barre n'arrive pas lorsque les iBars sont demandées, mais qu'elle arrive un moment après la demande. Alors il sera manqué par le système. C'est le but.
Et puis quoi, être accessible en permanence ? - Ce n'est manifestement pas la meilleure solution.
Mais si quelqu'un a besoin d'obtenir une nouvelle barre aussi rapidement que possible sans interroger OnTimer, il existe des interruptions personnalisées.
Si vous repensez le concept du bar ici, tout se mettra en place. Les ressources seraient économisées et la solution serait simple. À mon avis, la barre devrait être liée au temps, et non aux citations.
Il n'y a donc pas d'erreur dans mon code. Il existe une différence dans le concept des barres entre les plateformes.
Et qu'y a-t-il à discuter ? Lepolymorphisme dans sa forme pure. Règles OOP.
Il n'y a rien à discuter pour ceux qui sont au courant. Voici un exemple de l'histoire qui m'a amené à prendre la décision d'apprendre au moins un peu de la POO.
Ce n'est pas pour rien que j'ai pris comme exemple la fonction de définition d'une nouvelle barre. C'est avec cette fonction que tout a commencé. La fonction définissant une nouvelle barre au TF actuel a été écrite il y a longtemps. Soudain, j'en ai eu besoin aussi, mais en le détectant dans une certaine TF. Eh bien, pas de problème. Je l'ai réécrit en un demi-clic. Mais soudain, j'en ai besoin uniquement pour la TF actuelle. Pourquoi devrais-je passer PERIOD_CURRENT à cette fonction ? Pas de problème, je l'ai réécrite et maintenant j'ai deux fonctions avec des noms différents.
Je ne sais pas combien de fois je dois le réécrire ou me rappeler lequel je dois appeler. Et quand j'ai compris que je pouvais avoir plusieurs fonctions avec un seul nom et des paramètres d'entrée différents, mon agonie était terminée...
Il s'avère qu'il n'y a pas d'erreur dans mon code. Il existe une différence dans le concept des barres entre les plateformes.
A propos, si dans ma solution, il suffit de changer la fréquence de remplissage du tableau et qu'au lieu de faire une pause par minute, on accède une fois par seconde, alors le problème peut être complètement résolu. Dans ce cas, il est peu probable que la charge du système augmente. Vous pouvez le vérifier.
Remplacer if(Minute*Timer_fréquence >= 60000) par if(Minute*Timer_fréquence >= 1000).
Désolé, Pyotr, mais ton code n'est qu'un chaos.