Il y a un autre bug en jeu. Nous fixons un ordre Limit au prix actuel et observons son remplissage progressif. Nous vérifions le lot total de toutes les positions et de tous les ordres à chaque étape. Il ne doit pas changer, et doit être égal à celui qui a été envoyé à OrderSend.
// Демонстрация потери данных во время торговли.template <typename T>
T MyPrint( const T Value, conststring Str )
{
Print(Str + " = " + (string)Value);
return(Value);
}
#define _P(A) MyPrint(A, ": " + #A)
sinputdouble inLots = 100;
intOnInit()
{
MqlTradeResult Result = {0};
MqlTradeRequest Request = {0};
Request.action = TRADE_ACTION_PENDING;
Request.symbol = _Symbol;
Request.volume = inLots;
Request.price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
Request.type = ORDER_TYPE_BUY_LIMIT;
return(OrdersTotal() || PositionsTotal() || !OrderSend(Request, Result)); // Работаем, когда ничего не открыто.
}
// Возвращает сумму лотов всех позиций и ордеров.double GetSumLots()
{
double Lots = 0;
for (int i = _P(OrdersTotal()) - 1; i >= 0; i--)
if (_P(OrderGetTicket(_P(i))))
Lots += _P(OrderGetDouble(ORDER_VOLUME_CURRENT));
for (int i = _P(PositionsTotal()) - 1; i >= 0; i--)
if (_P(PositionGetTicket(_P(i))))
Lots += _P(PositionGetDouble(POSITION_VOLUME));
return(Lots);
}
voidOnTradeTransaction(constMqlTradeTransaction& trans,
constMqlTradeRequest& request,
constMqlTradeResult& result)
{
Print("---------");
// Проверяем, что сумма лотов всех позиций и ордеров совпадает с заданной.if (NormalizeDouble(_P(GetSumLots()) - inLots, _Digits))
Alert("BUG!");
}
100 lots ont été placés, mais à un moment donné, les lots sont devenus 72,8. Évidemment, l'algorithme de négociation peut être désorienté dans une telle situation.
En fait, non, il y a une chance d'avoir une erreur de synchronisation, ce qui arrive, il n'y a pas de solution facile.
Je n'ai même pas de solution simple. La façon de s'assurer qu'il y a une désynchronisation dans un script en cours d'exécution n'est pas du tout claire.
Je n'ai même pas de solution compliquée. La façon de s'assurer qu'il y a une asynchronie dans tout script en cours d'exécution n'est pas du tout claire.
Si le lot total a changé, continuez à compter jusqu'à ce que les lots des ordres et des positions soient deux fois identiques.
Le risque de désynchronisation est minime, voire de quelques pour cent, et n'affecte donc pas du tout les performances.
__________
J'ai regardé vos impressions, c'est peut-être un bug, si c'est un cas d'async, le mauvais montant ne devrait pas être répété de la même façon dans plusieurs calculs
Si le lot total a changé, continuez à compter jusqu'à ce que les lots des ordres et des positions soient deux fois identiques.
La probabilité de désynchronisation est de l'ordre d'une fraction ou de quelques pour cent, de sorte que les performances ne sont pratiquement pas affectées.
Dans le journal ci-dessus, trois calculs consécutifs donnent un résultat erroné. Nous avons besoin du sommeil, mais cela peut entraîner des retards, car nous n'aurons pas le temps de réagir à l'ordre commercial émis.
Vous ne devriez pas être offensé. La probabilité la plus élevée est une erreur dans le code. En deuxième position, on trouve l'écart exorbitant. Mais qui d'autre que vous peut écarter la première option et commencer à envisager la seconde sans voir le code. J'espère que les modérateurs déplaceront le sujet vers le mauvais.
Merci pour cette réponse adéquate. Je ne suis pas offensé, je suis contrarié)). J'ai écrit pour essayer de trouver une solution rapide, peut-être quelqu'un qui a déjà rencontré ce problème. Le code est absolument standard, une boucle totalprofit qui additionne et compare à une valeur donnée, de plus le code fonctionne depuis quelques mois sur deux comptes différents sans faillir. Passez une bonne journée.
Merci pour cette réponse adéquate. Je ne suis pas offensé, je suis attristé)). J'ai écrit pour essayer de trouver une solution rapide, que peut-être quelqu'un qui a déjà rencontré ce problème a trouvé. Le code est absolument standard, une boucle totalprofit qui additionne et compare à une valeur donnée, de plus le code fonctionne depuis quelques mois sur deux comptes différents sans faillir. Passez une bonne journée.
Résultat.
100 lots ont été placés, mais à un moment donné, les lots sont devenus 72,8. Évidemment, l'algorithme de négociation peut être désorienté dans une telle situation.
Chaîne de recherche: Oshibka 011.fxsaber:
Он должен быть неизменным - равным тому, что был отправлен в OrderSend.
En fait, non, il y a une chance d'être désynchronisé, ce qui arrive, il y a une solution de contournement, il n'y a pas de solution facile du tout.
En fait, non, il y a une chance d'avoir une erreur de synchronisation, ce qui arrive, il n'y a pas de solution facile.
Je n'ai même pas de solution simple. La façon de s'assurer qu'il y a une désynchronisation dans un script en cours d'exécution n'est pas du tout claire.
Je n'ai même pas de solution compliquée. La façon de s'assurer qu'il y a une asynchronie dans tout script en cours d'exécution n'est pas du tout claire.
Si le lot total a changé, continuez à compter jusqu'à ce que les lots des ordres et des positions soient deux fois identiques.
Le risque de désynchronisation est minime, voire de quelques pour cent, et n'affecte donc pas du tout les performances.
__________
J'ai regardé vos impressions, c'est peut-être un bug, si c'est un cas d'async, le mauvais montant ne devrait pas être répété de la même façon dans plusieurs calculs
Si le lot total a changé, continuez à compter jusqu'à ce que les lots des ordres et des positions soient deux fois identiques.
La probabilité de désynchronisation est de l'ordre d'une fraction ou de quelques pour cent, de sorte que les performances ne sont pratiquement pas affectées.
Dans le journal ci-dessus, trois calculs consécutifs donnent un résultat erroné. Nous avons besoin du sommeil, mais cela peut entraîner des retards, car nous n'aurons pas le temps de réagir à l'ordre commercial émis.
Ce n'est pas une situation agréable.
Dans le journal ci-dessus, trois calculs consécutifs donnent un résultat erroné.
Oui, j'ai vu ça, je l'ai ajouté en haut.
Vous ne devriez pas être offensé. La probabilité la plus élevée est une erreur dans le code. En deuxième position, on trouve l'écart exorbitant. Mais qui d'autre que vous peut écarter la première option et commencer à envisager la seconde sans voir le code. J'espère que les modérateurs déplaceront le sujet vers le mauvais.
Merci pour cette réponse adéquate. Je ne suis pas offensé, je suis contrarié)). J'ai écrit pour essayer de trouver une solution rapide, peut-être quelqu'un qui a déjà rencontré ce problème. Le code est absolument standard, une boucle totalprofit qui additionne et compare à une valeur donnée, de plus le code fonctionne depuis quelques mois sur deux comptes différents sans faillir. Passez une bonne journée.
Merci pour cette réponse adéquate. Je ne suis pas offensé, je suis attristé)). J'ai écrit pour essayer de trouver une solution rapide, que peut-être quelqu'un qui a déjà rencontré ce problème a trouvé. Le code est absolument standard, une boucle totalprofit qui additionne et compare à une valeur donnée, de plus le code fonctionne depuis quelques mois sur deux comptes différents sans faillir. Passez une bonne journée.
Il ne s'agit pas du sujet des caractéristiques.
Je suis d'accord.