Aleksey Lebedev: Dans PositionGet sans le PositionSelect au préalable.
PositionSelect est appelé à chaque tick et avant la dernière sortie d'information dans le bloc 3, cela fonctionnera également. Ce n'est donc manifestement pas la raison.
Yury Kirillov: Vous avez tort. PositionSelect est appelé à chaque tick et avant la dernière sortie d'information dans le bloc 3, cela fonctionnera aussi. Donc, la raison n'est évidemment pas dans ce cas.
Parfois, je me trompe, mais ce n'est pas le cas, clairement dans ce)
Les valeurs ne sont pas mises à jour après OrderSend.
Si PositionSelect(...)==false, il n'y a aucun intérêt à PositionGet.
Ainsi, après OrderSend, les données de position peuvent être récupérées, mais pas immédiatement... l'asynchronie est un mal.
Je serais volontiers d'accord - je n'ai pas honte d'admettre mes erreurs. Mais regardez : avant d'entrer dans le bloc 3, au tout début du handler OnTick(), la PositionSelect() que vous avez mentionnée est appelée, et aucun OrderSend() n'est exécuté. Dans le code, j'ai intentionnellement ajouté un compteur de retard de 1000 ticks entre l'exécution des blocs 1, 2 et 3 - il s'agit d'asynchronie, je pense que dans le testeur, c'est plus que suffisant pour fixer la position. En outre, j'ai modifié la condition du bloc 3 :
ne devrait pas compiler... PositionSelect(_Symbole
Corrigé _Symbole.
Conclusion : vous aviez raison ! Maintenant, le bloc 3 ne fonctionne pas, ce qui signifie que la position n'est pas sélectionnée. Merci pour le dialogue ! :-)
Les cuillères ont été retrouvées, mais les résidus restent : s'il n'y a plus de position, comment le volume de la position peut-il être de 1 ?
Ce qui ne correspond pas à la documentation :
Функция PositionSelect() копирует данные о позиции в программное окружение, и последующие вызовы PositionGetDouble(), PositionGetInteger() и PositionGetString()
возвращают ранее скопированные данные. Это означает, что самой позиции может уже и не быть (или же она изменилась по объему, направлению и т.д.),
а данные этой позиции можно еще получать. Для гарантированного получения свежих данных о позиции рекомендуется вызывать функцию PositionSelect()
непосредственно перед обращением за ними.
Donc, appelerPositionSelect() avec un résultat de false ne met pas à jour les informations de position ? Dommage !
Il me semble qu'il serait plus logique de continuer à nettoyer les déchets dans le tampon lorsqu'une position manquante est détectée. Juste au cas où...
Dans PositionGet sans le PositionSelect au préalable.
Michael, faisons une autre "feuille" avec des retards, ça devient ennuyeux. :))))
Quand allez-vous à l'ouverture ? :)))))))
Vous avez tort. PositionSelect est appelé à chaque tick et avant la dernière sortie d'information dans le bloc 3, cela fonctionnera aussi. Donc, la raison n'est évidemment pas dans ce cas.
Parfois, je me trompe, mais ce n'est pas le cas, clairement dans ce)
Les valeurs des données de position au moment où PositionSelect est appelé.
Les valeurs ne sont pas mises à jour après OrderSend.
Si PositionSelect(...)==false, il n'y a aucun intérêt à PositionGet.
Ainsi, après OrderSend, les données de position peuvent être récupérées, mais pas immédiatement... l'asynchronie est un mal.
Parfois, je me trompe, mais ce n'est pas le cas, clairement dans ce)
Les valeurs des données de position au moment où PositionSelect est appelé.
Les valeurs ne sont pas mises à jour après OrderSend.
Si PositionSelect(...)==false, il n'y a aucun intérêt à PositionGet.
Ainsi, après OrderSend, les données de position peuvent être récupérées, mais pas immédiatement... l'asynchronie est un mal.
Je serais volontiers d'accord - je n'ai pas honte d'admettre mes erreurs. Mais regardez : avant d'entrer dans le bloc 3, au tout début du handler OnTick(), la PositionSelect() que vous avez mentionnée est appelée, et aucun OrderSend() n'est exécuté. Dans le code, j'ai intentionnellement ajouté un compteur de retard de 1000 ticks entre l'exécution des blocs 1, 2 et 3 - il s'agit d'asynchronie, je pense que dans le testeur, c'est plus que suffisant pour fixer la position. En outre, j'ai modifié la condition du bloc 3 :
{if((gTicks>3000)&&(Step==2)&&(PositionSelect())) { Print("INFO>> *** VOLUME=",PositionGetDouble(POSITION_VOLUME), " *** ID=",PositionGetInteger(POSITION_IDENTIFIER), " *** TYPE=",EnumToString((ENUM_POSITION_TYPE)PositionGetInteger(POSITION_TYPE)), " *** OrdersTotal()=",OrdersTotal()); Step=3; return; }}//if((gTicks>3000)&&(Step==2))Le résultat n'a pas changé : l'ordre de fermer la position est exécuté, mais la taille de la position reste égale à 1.
:-(
{if((gTicks>3000)&&(Step==2)&&(PositionSelect()))ne devrait pas compiler... PositionSelect(_Symbole)
ne devrait pas compiler... PositionSelect(_Symbole)
ne devrait pas compiler... PositionSelect(_Symbole
Corrigé _Symbole.
Conclusion : vous aviez raison ! Maintenant, le bloc 3 ne fonctionne pas, ce qui signifie que la position n'est pas sélectionnée. Merci pour le dialogue ! :-)
Les cuillères ont été retrouvées, mais les résidus restent : s'il n'y a plus de position, comment le volume de la position peut-il être de 1 ?
Ce qui ne correspond pas à la documentation :
Donc, appelerPositionSelect() avec un résultat de false ne met pas à jour les informations de position ? Dommage !
Donc, appelerPositionSelect() avec un résultat de false ne met pas à jour les informations de position ? Dommage !
Cela fait maintenant 10 mois. .....