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
En fait, le message contient jusqu'à 8 octets d'informations, qui peuvent être interprétées comme on le souhaite. Il peut être de type date, double, 4 short, 8 char, ou 64 bits bit par bit.
Avec les quatre, 4 octets de magie suffisaient pour coder n'importe quoi, mais maintenant nous en avons 8. Tout ce dont vous avez besoin est un souhait.
Je sais, je l'ai très bien utilisé en 4, et j'ai lu l'article (j'ai beaucoup aimé l'idée).
Ici, ce n'est pas clair - Pourquoi différents types sont spécifiés à différents endroits ?
Veuillez indiquer comment fermer une position avec un TP et un SL, si le prix est proche du TP et que vous devez sortir maintenant.
J'envoie un ordre pour ouvrir une nouvelle position de volume égal. Dans la plupart des cas, cela fonctionne. Mais parfois, j'ai une situation où une position a le temps de se fermer par TP et au lieu de se fermer, j'obtiens une nouvelle position sur le marché... :(
Comment indiquer que la position ouverte concerne la fermeture d'une position existante, et si la position principale a déjà été fermée, ne pas en ouvrir une nouvelle ?
Je peux penser à des options comme "supprimer le SL et le TP avant la clôture ou attendre la clôture du TP", mais ce ne sont pas de belles solutions. Ne pouvons-nous pas effectuer une opération aussi simple que CLOSE une position comme nous le faisions dans MT4 ?
Recherchez PositionClose dans la classe CTrade.
Je suis sûr que ce sera la même chose que la vôtre. Une conclusion s'impose : il n'y a pas d'autre solution.
Mais je soutiens votre demande. Je demande aux développeurs de considérer cette variante.
Ajout du type d'opération TRADE_ACTION_CLOSE - fermeture d'une position pour un symbole spécifié dans son volume au prix actuel.
En fait, le message contient jusqu'à 8 octets d'informations, qui peuvent être interprétées comme on le souhaite. Il peut être de type date, double, 4 short, 8 char, ou 64 bits bit par bit.
Avec les quatre, 4 octets de magie suffisaient pour coder n'importe quoi, mais maintenant nous en avons 8. Ce ne serait qu'un vœu pieux.
Environ 8 octets dans long et ulong étaient clairs dans la référence. Ce qui est troublant, c'est l'utilisation incohérente de ces types en ce qui concerne la magie.
Un exemple simple : il est acceptable d'attribuer request.magic=ULONG_MAX-1 lors de l'envoi d'une demande de transaction. Pourquoi le manuel de référence indique-t-il que la fonction OrderGetInteger(ORDER_MAGIC) ne renvoie que le type long ? En outre, magic renvoie également le type long pour les positions et les transactions.
Alors, comment a-t-il été conçu à l'origine ? Peut-être devrions-nous préciser pour lastructure MqlTradeRequest que magic est de type long, car les fonctions HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() etc. ne sont pas destinées à renvoyer des valeurs entières supérieures à LONG_MAX ?
Les 8 octets de long et ulong ont été clarifiés dans le manuel de référence. L'utilisation incohérente de ces types par rapport à la magie est troublante.
Un exemple simple : lors de l'envoi d'une demande de transaction, il est acceptable d'attribuer request.magic=ULONG_MAX-1. Pourquoi le manuel de référence indique-t-il que la fonction OrderGetInteger(ORDER_MAGIC) ne renvoie que le type long ? En outre, magic renvoie également le type long pour les positions et les transactions.
Alors, comment a-t-il été conçu à l'origine ? Peut-être devrions-nous préciser pour lastructure MqlTradeRequest que magic est de type long, car les fonctions HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() etc. ne sont pas destinées à renvoyer des valeurs entières supérieures à LONG_MAX ?
En fait, le magik est de type long (cela peut être facilement vérifié en formant un magik négatif et un magik avec une valeur en dehors de la plage de valeurs du type long).
Pour le vérifier, nous pouvons modifier légèrement le Night Expert Advisor (il n'utilise pas les classes de la bibliothèque standard).
Pour que l'expérience soit propre, nous devons changer le type de paramètre EA_Magic en long et dérouler le magicien du dernier ordre dans l'historique (si l'ordre a été fixé avec succès).
Interesting:
В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long).
Si c'est le cas, il est nécessaire de clarifier la description de l'élément magique de la structureMqlTradeRequest en supprimant "u"du nom du type.
En fait, le message contient jusqu'à 8 octets d'informations, qui peuvent être interprétées comme on le souhaite. Il peut être de type date, double, 4 short, 8 char, ou 64 bits bit par bit.
Avec les quatre, 4 octets de magie suffisaient pour coder n'importe quoi, mais maintenant nous en avons 8. Ce ne serait qu'un vœu pieux.
En fait, ce n'est pas 64 mais seulement 63 bits (c'est-à-dire 8 octets incomplets). Il y aurait 8 octets si on utilisait toute la gamme longue.
Mais malheureusement...
D'une part, un ulong magique est passé dans la structure MqlTradeRequest. Cela signifie que seules des valeurs positives peuvent être définies.
En revanche, lesfonctions PositionGetInteger/OrderGetInteger renvoient le type long. Cela signifie que la moitié de la gamme ulong est coupée.
Ce que nous avons en fait, c'est 63 bits au lieu des 64 bits décrits ci-dessus. En fait, ce n'est pas tant une mauvaise chose qu'un grand inconvénient pour les principes du contrôle des ordres.
Il serait beaucoup plus pratique d'utiliser le même système que dans MT4 - autoriser les magiciens avec un signe. Étant donné que de nombreux systèmes de trading reposent sur un principe simple utilisant le symbole même d'un magicien. Il est en effet beaucoup plus facile de diviser un système en deux et de filtrer vos ordres à l'aide de la fonction habituelle MathAbs( OrderMagicNumber() ).
En fait, ce n'est pas 64 mais seulement 63 bits (c'est-à-dire 8 octets incomplets). 8 octets le seraient si toute la gamme longue était utilisée.
Vous vous trompez.
Les 64 bits sont utilisés et c'est à vous de voir comment vous les utilisez. Long/ulong ne fait aucune différence, tout dépend de la façon dont vous interprétez ces 64 bits. Si vous voulez utiliser long comme un long signé - utilisez-le, si vous voulez l'utiliser comme un ulong non signé - pas de problème. Si vous voulez utiliser d'autres types de données dans ces 64 bits, faites-le.
C'est exactement ce que Slava a écrit.
En fait, ce n'est pas 64 mais seulement 63 bits (c'est-à-dire 8 octets incomplets). 8 octets le seraient si toute la gamme longue était utilisée.
Mais malheureusement...
D'une part, un ulong magique est passé dans la structure MqlTradeRequest. Cela signifie que seules des valeurs positives peuvent être définies.
En revanche, lesfonctions PositionGetInteger/OrderGetInteger renvoient le type long. Cela signifie que la moitié de la gamme ulong est coupée.
Au total, nous avons 63 bits au lieu des 64 bits décrits ci-dessus. En fait, ce n'est pas tant une mauvaise chose qu'un grand inconvénient pour les principes du contrôle des ordres.
Il serait beaucoup plus pratique d'utiliser le même système que dans MT4 - autoriser les magiciens avec un signe. Étant donné que de nombreux systèmes de trading reposent sur un principe simple utilisant le symbole même d'un magicien. Il est en effet beaucoup plus facile de diviser un système en deux et de filtrer vos ordres à l'aide de la fonction habituelle MathAbs( OrderMagicNumber() ).
Honnêtement, je suis perplexe. Vous en faites trop pour rien. Absolument pas. Ce problème n'existe pas, vous venez de l'inventer. Réglez les conversions de type jusqu'à la fin.
J'espère que l'article ci-dessous vous aidera. Copiez-le dans un script, compilez-le, exécutez-le dans le terminal, puis réfléchissez bien. Bonne chance.