MetaEditor build 1490 - page 6
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
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
Depuis quelque temps, lorsqu'une position est retournée, son ID de position est CHANGÉ. Cela est indiqué dans l'aide. D'où les incohérences.
Ce n'est pas le problème.
Le Service Desk a dit qu'ils allaient le corriger, un correctif sera disponible dans la version d'aujourd'hui.
Le Service Desk a répondu qu'un correctif sera disponible dans la version d'aujourd'hui.
1491 - n'a pas été corrigé.
Malheureusement - non.
D'ailleurs, il n'est pas du tout clair comment le système actuel de comptabilisation des positions séparera la partie de la position qui a clôturé la position précédente et la partie restante de la nouvelle position (cette division n'existe pas actuellement). Il semble que le problème soit plus profond qu'il n'y paraît à première vue.
Malheureusement - non.
D'ailleurs, il n'est pas du tout clair comment le système actuel de comptabilisation des positions séparera la partie de la position qui a fermé la position précédente et la partie restante de la nouvelle position (cette division n'existe pas actuellement). Il semble que le problème soit plus profond qu'il n'y paraît à première vue.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
MetaEditor build 1490
fxsaber, 2016.12.05 11:32
Oui, même siDEAL_ENTRY_INOUT est inclus dans le nombre de transactions de la position, il ne sera d'aucune utilité à moins que vous n'étendiez ENUM_DEAL_PROPERTY_*.A peu près la même chose
A mon avis, au contraire, l'énumération ne doit pas être étendue, mais raccourcie.DEAL_ENTRY_INOUT est doncune entité inutile qui ne fait rien.
Voici un exemple de ce à quoi il ressemble maintenant
IN ; +1.0 ; ID 0
IN ; +0,2 ; ID 0
IN/OUT ; -2.0 ; ID 1 // une nouvelle position avec un nouvel ID a été créée mais il n'y a pas de transactions dedans ; toutes les transactions se réfèrent à la position précédente ; par conséquent, la commission et les swaps sont de 0,0.
IN ; +0.2 ; ID 1 // la première transaction est apparue dans la liste et c'est la seule.
ainsi une partie du volume n'a pas été déplacée vers une nouvelle position et n'est affichée nulle part, par conséquent les swaps et les commissions ne seront pas pris en compte pour cette partie du volume dans la position ID 1 (listes de transactions correspondantes en bleu et vert)
C'est ainsi que je vois les choses, et c'est ainsi qu'elles devraient être logiquement et historiquement (la décision que prendra MQ n'est pas connue) :
IN ; +1.0 ; ID 0
IN ; +0,2 ; ID 0
OUT ; -1.2 ; ID 0 // la partie du volume de la transaction qui est allée à la position en cours de fermeture.
IN ; -0.8 ; ID 1 // une nouvelle position est apparue avec le nouvel ID, le métier est présent en tant que reste, le métier est dans la liste, et il est le premier.
IN ; +0.2 ; ID 1 // le deuxième trade de la liste
Ainsi, le type de transaction IN/Out n'est pas du tout nécessaire. De cette façon, tout est pris en compte correctement et les listes de transactions en positions sont complètes, nous pouvons obtenir de manière adéquate les valeurs des commissions et des swaps pour les transactions correspondantes. Et s'il s'avère nécessaire de déterminer quelles transactions (dont une partie a été clôturée et l'autre a permis d'ouvrir une nouvelle position) font partie d'un ordre, il sera très facile de le faire - les transactions OUT et IN ayant lieu en même temps (marquées en gras).
A mon avis, au contraire, l'énumération ne doit pas être étendue, mais raccourcie.DEAL_ENTRY_INOUT est doncune entité inutile qui ne donne rien.
Une transaction est une entité d'exécution qui ne dépend pas de la plate-forme. Et les drapeaux d'entrée sont une absurdité de la MQ.
S'il y avait une seule transaction sur le marché, vous ne pouvez pas la représenter comme deux, même si cela serait pratique.
MQ a fait tout son possible pour ajouter la virtualisation - le mode couverture. Faire même une simple virtualisation pour un échange est une mauvaise décision.
Mais l'extension des propriétés de la transaction offre la commodité sans les béquilles potentielles.
Une transaction est une entité d'exécution qui ne dépend en aucun cas de la plate-forme. Et les drapeaux d'entrée sont une invention de MQ.
S'il y avait une seule transaction sur le marché, vous ne pouvez pas la représenter comme deux, même si cela serait pratique.
MQ a fait des pieds et des mains pour ajouter la virtualisation - mode couverture. Faire même une simple virtualisation pour un échange est une mauvaise décision.
Mais l'extension des propriétés de la transaction offre une commodité sans béquilles potentielles.
Je ne faisais qu'exprimer mon opinion.
Et quel genre d'extension sauverait la journée ? Vous devez encore déterminer d'une manière ou d'une autre quelle partie de la transaction se rapporte à l'ancienne position et quelle partie se rapporte à la nouvelle.
Et quel type d'expansion permettrait de sauver la situation ? Il reste à déterminer quelle partie de l'accord concerne l'ancien poste et quelle partie concerne le nouveau.
1491 - Alpari-MT5-Demo. Les captures d'écran montrent le même endroit
Terminal
Testeur de tiques réelles
Les chandeliers ne correspondent pas les uns aux autres - dans le testeur, ils sont flous. De plus, les temps historiques du testeur et du terminal diffèrent d'une heure.
CopyTicks dans le terminal renvoie les mêmes données que dans le testeur - une heure de différence. Par conséquent, les ticks ne correspondent pas complètement aux barres.
Alors comment faire confiance à MT5, le testeur, quand il y a un auto-discrédit complet ? Pourquoi les développeurs ne disposent-ils pas d'EA de référence à faire tourner dans le testeur pour être sûrs qu'elles fonctionnent clairement ? C'est un désordre total.