Organiser le cycle de commande - 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
Cependant, il est préférable de ne pas le faire - tout doit être à sa place.
Dans le timer EA, nous prenons une liste selon les critères requis et à list.Total()>xxx nous faisons ce que nous voulons.
Il s'avère que dans l'ancien MQL4, où il n'y avait pas de minuterie, le problème n'avait pas de solution ? Pourquoi s'embêter avec la minuterie, alors que le problème peut être résolu en quelques lignes ?
C'est exactement ce que je regardais.
Et mon poste
Et, quel est le sens, dans le commerce réel, de courir continuellement après la boucle des ordres ? Et surtout, c'est une perte de temps...
Disposer d'une information toujours actualisée sur l'environnement commercial, et ne pas chercher chaque fois que nécessaire, mais se référer aux listes disponibles. Et comme les listes doivent toujours être à jour, il vaut la peine de veiller à les actualiser constamment, mais efficacement.
Après tout, si vous n'avez pas de listes, vous devrez chercher des informations lorsque vous en aurez besoin. Et pas seulement une fois par tic. Et c'est là qu'apparaîtront tous les freins liés au chargement répété de l'environnement.
Cependant, il est possible d'optimiser ce domaine également - si nous renonçons à contrôler les changements de l'environnement et ne remplissons les listes que lorsque cela est nécessaire. Mais vous perdriez alors la capacité de l'EA à réagir aux actions manuelles de fermeture/modification/ouverture de l'utilisateur.
Il s'avère que dans l'ancien MQL4, où il n'y avait pas de minuterie, le problème n'avait pas de solution ? Pourquoi s'embêter avec une minuterie quand le problème peut être résolu en quelques lignes ?
Lorsqu'il était impossible de le faire, nous devions réfléchir à la manière de le résoudre. Mais c'est possible maintenant ;)
Disposer d'informations toujours actualisées sur l'environnement commercial, et ne pas avoir à chercher chaque fois que nécessaire, mais se référer aux listes existantes. Comme les listes doivent toujours être à jour, il vaut la peine de veiller à ce qu'elles le soient en permanence, mais de manière efficace.
Après tout, si vous n'avez pas de listes, vous devrez chercher des informations lorsque vous en aurez besoin. Et pas seulement une fois par tic. Et là, tous les ralentissements apparaîtront lors du chargement répété de l'environnement.
Cependant, même ici, il est possible de l'optimiser - si vous refusez de contrôler les changements de l'environnement et ne remplissez les listes que lorsque cela est nécessaire. Mais alors, vous perdrez la capacité de l'EA à réagir aux actions de l'utilisateur sur la fermeture/modification/ouverture manuelle.
C'est le mot clé"mais efficace". Et quel est le sens profond de la mise à jour de la liste toutes les millisecondes si la liste ne peut changer que lorsque le prochain tick arrive ? Et pourquoi pas une seule fois par tic ? Un ordre peut-il être clôturé en dehors d'un tick ? Comme je le vois, même s'il n'y a pas de tick et que l'EA envoie une commande d'ouverture/fermeture, c'est-à-dire qu'il modifie l'environnement, c'est-à-dire la liste, cette action provoquera un tick. Si ce n'est pas le cas, la liste ne sera pas modifiée en l'absence d'une tique causée par quelque chose d'autre. N'est-ce pas ?
Voici le mot-clé"mais efficacement". Et quel est le sens profond de la mise à jour de la liste à chaque milliseconde, si la liste ne peut changer qu'à la réception du prochain tick ? Et pourquoi pas une seule fois par tic ? Un ordre peut-il être clôturé en dehors d'un tick ? Comme je le vois, même s'il n'y a pas de tick et que l'EA envoie une commande d'ouverture/fermeture, c'est-à-dire qu'il modifie l'environnement, c'est-à-dire la liste, cette action provoquera un tick. Si ce n'est pas le cas, la liste ne sera pas modifiée en l'absence d'une tique causée par quelque chose d'autre. N'est-ce pas ?
Dans le testeur, j'exécute OnTimer(), qui crée des listes juste à partir de OnTick(), mais dans la vie réelle, cela ne fait pas de différence...
Mais là, un minuteur n'est pas seulement nécessaire pour la création de listes. En somme, tout ce dont nous avons besoin en même temps. Pour l'instant. Un profilage plus poussé montrera les goulots d'étranglement.
C'est le mot clé"mais efficacement". Et quel est le sens profond de la mise à jour de la liste toutes les millisecondes, si la liste ne peut être modifiée qu'avec l'arrivée d'un autre tick ? Et pourquoi pas une seule fois par tic ? Un ordre peut-il être clôturé en dehors d'un tick ? Comme je le vois, même s'il n'y a pas de tick et que l'EA envoie une commande d'ouverture/fermeture, c'est-à-dire qu'il modifie l'environnement, c'est-à-dire la liste, cette action provoquera un tick. Ou si ce n'est pas le cas, alors sans un tic causé par quelque chose d'autre, la liste ne sera pas modifiée. N'est-ce pas ?
Il n'est pas inutile de forcer les minuteurs si le programme fonctionne avec de nombreux symboles - les ticks arrivent à des moments différents.
Mais cela n'a aucun sens de rechercher "non pas votre" liste d'ordres, mais celle créée par le terminal, ce qui est la raison des problèmes que pose la modification de la liste par quelqu'un d'autre.
Il n'est pas inutile de forcer les minuteurs si le programme fonctionne avec de nombreux symboles - les tics arrivent à des moments différents.
Mais cela n'a pas de sens de rechercher "non pas votre propre" liste d'ordres, mais la liste créée par le terminal, ce qui est la raison des problèmes lorsque la liste est modifiée par quelqu'un d'autre.
Dans le cas de la liste "pas la vôtre", il existe un nombre total de commandes que l'on peut stocker dans une variable statique et exécuter la boucle pour énumérer l'environnement au fur et à mesure qu'il change. Mais pas chaque milliseconde...
Dans le cas où la liste n'est "pas la vôtre", il existe un nombre total de commandes qui peut être stocké dans une variable statique et exécuter une boucle pour relancer l'environnement au fur et à mesure qu'il change. Mais pas chaque milliseconde...
Vous ne pouvez pas attraper le déclenchement d'un ordre en attente de cette façon.
Il n'est pas possible d'attraper le déclenchement d'un ordre en attente de cette manière.
Nous ne parlons donc pas d'attraper les puces, c'est-à-dire l'ordre en attente, mais d'essayer tous les ordres à chaque milliseconde.
Il ne s'agit donc pas d'attraper des puces, c'est-à-dire des commandes en attente, mais de passer en revue toutes les commandes à chaque milliseconde.
- A quoi sert une poêle à frire ?
- Par exemple, pour faire frire des œufs.
- Il ne s'agit pas d'oeufs brouillés, il s'agit de la poêle à frire...