Séquence d'exécution de Init() et DeInit() - page 14
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
OK. Les prises de courant en sont un exemple malheureux.
Alors prenons-en un autre - sauter du balcon ! Le CA interdit-il de sauter du balcon ? - Non ? - Alors pourquoi ne pas vous entraîner pour l'adrénaline ?
Tout objectif doit être atteint par des moyens sains, sinon les objectifs sont irrationnels.
Le balcon est également un mauvais exemple. Les balcons ont des garde-corps et même leur hauteur est réglementée par le code du bâtiment. Mais dans votre propre maison, vous pouvez enlever la balustrade du balcon, vous comprenez et ne sauterez pas du balcon.
Le balcon est également un exemple malheureux. Les balcons sont munis de garde-corps et leur hauteur est réglementée par la réglementation. Vous pouvez retirer la main courante du balcon à la maison. Vous comprenez et ne sauterez pas du balcon.
Vous parliez de ce que le CC ne vous interdit pas de faire. Sauter du balcon n'est pas interdit par le CC. Appuyer rapidement sur le bouton d'alimentation d'un ordinateur n'est pas interdit par le CC. La CA n'interdit pas beaucoup de choses à faire, mais personne ne le fera dans son bon sens.
Mais vous voulez changer le TF.... souvent. Je me demande pourquoi. Juste parce que le Royaume-Uni ne l'interdit pas ? - mais c'est une critique, pas un souhait pour MQ.
Vous parliez de ce que le CC ne vous interdit pas de faire. Sauter du balcon n'est pas interdit par le CC. Appuyer rapidement sur le bouton d'alimentation d'un ordinateur n'est pas interdit par le CC. Le CC n'interdit pas beaucoup de choses, mais aucune personne saine d'esprit ne les ferait.
Mais vous voulez changer le TF.... souvent. Je me demande pourquoi ! Juste parce que le Royaume-Uni ne l'interdit pas ? - Mais c'est une critique, pas un souhait pour MQ.
Je n'ai pas écrit un tel souhait. Le fait est que cela peut arriver. Imaginez que dans votre réfrigérateur domestique, l'ampoule dans laquelle lorsque vous ouvrez la porte est soit allumée soit éteinte, vous avez besoin d'une certaine vitesse pour ouvrir la porte, ce qui fonctionnerait correctement. N'est-ce pas du crétinisme ?
Je suis étonné, n'êtes-vous pas un ingénieur de conception? Ou êtes-vous à la tête d'un groupe d'art amateur dans un centre culturel ? Vous ne comprenez pas les principes de base de la conception.
Je n'ai pas écrit une telle chose que je veux qu'elle se produise. Le fait est que cela peut arriver. Imaginez un réfrigérateur dans votre maison dont l'ampoule s'allume et s'éteint lorsque vous ouvrez la porte et que vous devez ouvrir la porte à une certaine vitesse pour qu'elle fonctionne correctement. N'est-ce pas du crétinisme ?
Je suis étonné, n'êtes-vous pas un ingénieur de conception ? Ou êtes-vous à la tête d'un groupe d'art amateur dans un centre culturel ? Vous ne comprenez pas les principes de base de la conception.
C'est vous qui ne comprenez pas les principes de conception.
Il existe un merveilleux proverbe : "Donnez à un idiot un verre ***, il le cassera *** et se coupera les mains."
Je vous l'ai demandé deux fois : pourquoi avez-vous besoin de changer fréquemment de TF ? Quel est le sens pratique de ces gestes (actions de programme) ? Je n'ai pas obtenu de réponse.
Je ne vais pas participer à des discussions idiotes sur la façon dont on peut casser quelque chose volontairement, je suis un ingénieur, pas un terminator.
C'est vous qui ne comprenez pas les principes de conception.
Il existe un merveilleux proverbe : "Donnez à un fou un verre ***, il se cassera le *** et se coupera les mains".
Je vous ai posé 2 fois la question : pourquoi avez-vous besoin de changer fréquemment de TF ? Quel est le sens pratique de ces gestes (actions de programme) ? Je n'ai pas obtenu de réponse.
Je ne vais pas participer à des discussions idiotes sur la façon dont on peut casser quelque chose volontairement, je suis un ingénieur, pas un terminator.
Avez-vous commencé à porter un badge de l'enseignement supérieur ?
Je propose de supprimer tout ce qui se trouve à partir du post 125, comme n'étant pas pertinent pour une discussion constructive sur le problème de l'ordre deinit et init lors du changement de TF.
C'est une perte de temps, c'était une discussion très constructive et éclairante.
C'est vous qui ne comprenez pas les principes de conception.
Il existe un merveilleux proverbe : "Donnez à un fou un verre ***, il se cassera le *** et se coupera les mains".
Je vous ai posé 2 fois la question suivante : pourquoi avez-vous besoin de changer fréquemment de TF ? Quel est le sens pratique de ces gestes (actions de programme). Je n'ai pas reçu de réponse.
Lorsque vous comprenez les principes de conception, il devrait être clair que l'absence de râteau est bonne et que sa présence est mauvaise, et que l'analogie avec le proverbe est inappropriée.
Concernant les questions. Tout d'abord, pourquoi s'accrocher à la phrase sur les "changements fréquents" ? Avec la mise en œuvre actuelle, la fréquence n'a aucun effet sur le problème - il peut se manifester avec une commutation unique également. Et deuxièmement, pour répondre en substance, par exemple, le même Slawa a recommandé d'appeler ChartSetSymbolPeriod comme un moyen "moderne" de rafraîchir les graphiques hors ligne. Il n'y a aucune garantie que ce savoir-faire ne sera pas intégré dans quelques indicateurs sur un graphique et déclenché dans un court laps de temps.
Je comprends qu'il est peu probable que la situation change, mais demandons au moins à MQ d'expliciter toute cette belle logique actuelle dans l'aide, ainsi que tous les détails concernant les différences entre les EA et les indices, le passage d'une période à l'autre, et les codes de raison de désinitialisation (en particulier, l'aide refuse toujours le code 3 pour les indicateurs).
Si l'on comprend les principes de conception, il devrait être clair que l'absence de râteau est une bonne chose et que le fait d'avoir un râteau est mauvais, et que l'analogie avec le proverbe est déplacée.
En ce qui concerne les questions. Tout d'abord, pourquoi s'accrocher à la phrase sur les "changements fréquents" ? Avec la mise en œuvre actuelle, la fréquence n'a aucun effet sur le problème - il peut se manifester avec une commutation unique également. Et deuxièmement, pour répondre en substance, par exemple, le même Slawa a recommandé d'appeler ChartSetSymbolPeriod comme un moyen "moderne" de rafraîchir les graphiques hors ligne. Il n'y a aucune garantie que ce savoir-faire ne sera pas intégré dans quelques indicateurs sur un graphique et déclenché dans un court laps de temps.
Je comprends qu'il est peu probable que la situation change, mais demandons au moins à MQ d'expliciter toute cette belle logique actuelle dans l'aide, ainsi que tous les détails sur les différences entre les EA et les indices, les commutations vers le haut et vers le bas par période de temps, et sur les codes de raison de désinitialisation (en particulier, l'aide refuse toujours le code 3 pour les indicateurs).
Le changement fréquent de TF est la seule chose que Dimitri a invoqué comme argument dans le sens qu'un imbécile peut faire. L'adage est donc très approprié.
La seule chose sur laquelle je peux être d'accord est que cela doit être documenté dans la référence. Et surtout détailler ce qui peut se comporter différemment dans les mêmes situations pour différents types de programmes.
Le changement fréquent de TF est la seule chose à laquelle Dmitry a fait appel comme argument dans le sens où un idiot peut le faire. L'adage est donc très approprié.
La seule chose sur laquelle je peux être d'accord est que cela doit être documenté dans la référence. Et surtout détailler ce qui peut se comporter différemment dans les mêmes situations pour différents types de programmes.
En fait, je viens de vous dire comment ça se passe avec init et deinit.
Mais en général, l'approche de l'ingénierie est super - que cela fonctionne ou non, parfois oui, parfois non) - ce n'est pas du tout un problème, ce n'est pas fatal.