Organiser le cycle de commande
Poursuivre le thème du lancement des bibliothèques MQL5 sous MT4
#property strict // https://www.mql5.com/ru/docs/standardlibrary/graphics/cgraphic #include <Graphics\Graphic.mqh> // MQL5\Include\Graphics\Graphic.mqh void OnStart() { double Y[] = {1, 2}; GraphPlot(Y); }
Souvent dans le testeur, si le curseur de vitesse est réglé sur 31, c'est lent, s'il est réglé sur 32, le test se précipite vers sa conclusion avec une super-vitesse.
Je m'en sors en insérant un délai à travers le compteur dans le code :
input int gDelay = 10000; // Счетчик для задержки, off=0 void OnTick() { int delayCount = 0; while(delayCount < gDelay) ++delayCount; }
Le délai par entrée peut être ajusté en fonction de la vitesse de l'EA et de la puissance du processeur.
À la vitesse 32, je peux maintenant me déplacer vers les points d'intérêt à la vitesse qui me convient.
Nous allons aborder ci-dessous un sujet qui ne concerne pas seulement MT4, mais aussi MT5 avec d'autres plateformes. Mais la logique sera écrite en MQL4 pour une perception facile, donc dans cette branche.
Le plus souvent, l'épine dorsale (la chair de tout ordre) de la modification/suppression d'un ordre se résume à la logique suivante
// Самый распространенный костяк логики модификации ордеров for (int i = OrdersTotal() - 1; i >= 0; i--) if (OrderSelect(i, SELECT_BY_POS)) OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration());
Maintenant, l'approche est rare, mais beaucoup plus correcte.
// Редкий, но правильный костяк модификации ордеров for (int i = OrdersTotal() - 1; i >= 0; i--) if (OrderSelect(i, SELECT_BY_POS)) if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration())) { i = OrdersTotal(); // Хотя бы так // А лучше так // OnTick(); break; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно) }
Après l'envoi d'un ordre de transaction, l'environnement commercial change, il est donc conseillé d'exécuter toute la logique commerciale du TS à partir de zéro immédiatement après la réponse du serveur commercial.
Maintenant, l'approche est rare, mais beaucoup plus correcte.
Cette variante s'accroche à modifier le dernier ordre de la liste à toute erreur, et le Conseiller Expert qui a plus d'un ordre "perd de vue" tous les autres.
Ma recette : passer en boucle tous ses ordres, traiter chacun d'entre eux (en mettant à jour les informations sur le marché avant de les traiter, si nécessaire), et au tick suivant, l'approche suivante. Dans certains cas, l'approche suivante (appel OnTick) peut être effectuée immédiatement après la fin de la boucle actuelle, s'il y a eu des erreurs dans celle-ci.
Cette option boucle sur la modification du dernier ordre de la liste en cas d'erreur, et un EA avec plus d'un ordre "perd de vue" tous les autres.
Il n'y aura pas de boucle à cause de cette condition.
if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration()))
Ma prescription : parcourez en boucle tous vos ordres, traitez chacun d'entre eux (en mettant à jour les informations sur le marché avant de les traiter, si nécessaire) et au tick suivant, l'approche suivante. Dans certains cas, l'approche suivante (appel OnTick) peut être effectuée juste après la fin de la boucle actuelle si celle-ci comportait des erreurs.
Ensuite, d'autres erreurs de demandes de transaction peuvent être vues dans le journal du terminal.
Il n'y aura pas de boucle à cause de cette condition.
Oui, faux, lisez-le comme !OrderModify.
Si la modification est réussie, le traitement ne peut pas non plus être répété depuis le début de la liste, car dans ce cas, un ordre sera également modifié (par exemple, remonté derrière le prix) et les autres risquent d'être laissés sans surveillance pendant un long moment.
Ma recette est toujours valable.
Je n'ai pas eu celui-là.
Si la modification est réussie, le traitement ne peut pas non plus être répété depuis le début de la liste, car dans ce cas, un ordre sera également modifié (par exemple en remontant derrière le prix), et les autres risquent d'être laissés sans surveillance pendant un long moment.
Il y a quelque chose qui cloche dans cette logique depuis le tout début. Nous devons faire un choix conscient : il est préférable d'avoir une commande réelle ou de nombreuses commandes non pertinentes.
Mon ordonnance est toujours valable.
Je n'ai pas eu celui-là.
Laissez le OrderModify s'exécuter pendant 5 secondes. Pendant son exécution, un ordre à cours limité partiel est exécuté plusieurs fois sur le serveur de négociation, générant une douzaine de transactions.
Quelque chose dans cette logique est faux dès le départ. Vous devez faire un choix conscient : mieux vaut une commande réelle ou de nombreuses commandes non pertinentes.
Un ordre ne peut pas être à différents niveaux en même temps. Ou devrions-nous avoir un EA différent pour chaque niveau ? C'est une solution discutable pour la grande majorité des stratégies.
Dans un cas particulier, plusieurs positions (gagnées par la tendance avec plusieurs entrées) et un stop suiveur pour celles-ci. Retirer le SL d'une seule transaction, ou les modifier toutes ? Lors d'un mouvement brusque avec un retour en arrière ultérieur tout aussi brusque, l'option consistant à ne modifier qu'un seul ordre perdra beaucoup (et nous n'arriverons pas au reste, car chaque nouvel appel à OnTick modifiera le tout premier ordre de la liste).
Laissez OrderModify fonctionner pendant 5 secondes. Pendant son exécution, supposons qu'un ordre à cours limité partiel a été exécuté plusieurs fois sur le serveur de négociation, ayant généré une douzaine de transactions.
Supposons que. Nous traiterons tous les ordres qui ont été (et devraient être) exécutés, et passerons aux nouveaux ordres sur le prochain tick ou directement après le premier cycle.
Sinon, nous risquons toujours de travailler avec une - dernière - partie exécutée d'une dernière commande. Peut-être la plus petite partie. Laisser une grosse commande suspendue sans surveillance.
Un ordre ne peut pas être à différents niveaux en même temps. Ou devrions-nous avoir une EA différente pour chaque niveau ? C'est une solution discutable pour la grande majorité des stratégies.
Dans un cas particulier, plusieurs positions (gagnées par la tendance avec plusieurs entrées) et un stop suiveur pour celles-ci. Retirer le SL d'une seule transaction, ou les modifier toutes ? Si nous avons une forte hausse suivie d'un recul tout aussi fort, l'option consistant à ne modifier qu'un seul ordre nous ferait perdre beaucoup (et nous n'atteindrons pas le reste, car chaque nouvel appel à OnTick modifiera le tout premier ordre de la liste).
Je ne comprends pas pourquoi OnTick ne modifierait qu'un seul ordre ? Ils seront tous modifiés.
Disons. Nous traiterons tous les ordres qui ont été (et devraient être) traités et passerons aux nouveaux ordres au prochain tick ou immédiatement après le premier cycle.
Sinon, nous risquons toujours de travailler avec un seul - le dernier - élément exécuté d'une dernière commande. Peut-être la plus petite partie. Laisser une grosse commande suspendue sans surveillance.
J'attire l'attention sur le mot "colonne vertébrale". La viande, sous la forme d'une sélection de lots prioritaires ou autre, peut toujours être construite. La logique de base, en revanche, reste la même : après un ordre de transaction réussi, on exécute toute la logique de transaction à partir de zéro.
Je ne comprends pas pourquoi OnTick ne modifie qu'un seul ordre ? Tout sera modifié.
Parce que le prix va bouger, et à chaque nouvel appel à OnTick, la condition pour une nouvelle modification du même ordre, premier de la liste, sera remplie. Surtout si la modification dure 5 secondes ;)
Notez le mot "colonne vertébrale". On peut toujours ajouter de la viande sous la forme d'une sélection prioritaire de lots ou autre. La logique de base, en revanche, reste la même : après un ordre de transaction réussi, on exécute toute la logique de transaction à partir de zéro.
Une telle "colonne vertébrale" briserait la logique d'un EA travaillant avec plus d'un ordre.
A quoi cela sert-il si cela ne donne aucun avantage aux systèmes avec une commande et gâche les autres ?
Trier par volume et/ou distance par rapport au prix avant de travailler avec les commandes est une bonne solution. Mais nous ne devrions pas supposer que tous ceux qui copient le code du forum l'implémenteront.
En ce sens, mon code est plus sûr.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation