Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
С некоторых пор, при перевороте позиции ее Position ID МЕНЯЕТСЯ. Это отображено в справке. Отсюда и нестыковки.
Проблема не в этом.
В сервисдеске ответили, что исправят, будет доступно исправление в сегодняшнем билде.
В сервисдеске ответили, что исправят, будет доступно исправление в сегодняшнем билде.
1491 - не исправили.
К сожалению - нет.
Кстати, вообще не понятно, как при существующей системе учета позиций будет разделятся часть позиции которая закрыла предыдущую и оставшаяся часть новой позиции (сейчас этого разделения нет). Похоже проблема глубже, чем может показаться на первый взгляд.
К сожалению - нет.
Кстати, вообще не понятно, как при существующей системе учета позиций будет разделятся часть позиции которая закрыла предыдущую и оставшаяся часть новой позиции (сейчас этого разделения нет). Похоже проблема глубже, чем может показаться на первый взгляд.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
MetaEditor build 1490
fxsaber, 2016.12.05 11:32
Да даже если DEAL_ENTRY_INOUT будет входить в число сделок позиции, толку от этого никакого ну будет, пока не расширите ENUM_DEAL_PROPERTY_*.Так об этом же
На мой взгляд наоборот, не расширить перечисление нужно, а сократить. Так DEAL_ENTRY_INOUT это лишняя сущность, которая ничего не даёт.
Приведу пример как это выглядит сейчас
IN; +1.0; ID 0
IN; +0.2; ID 0
IN/OUT; -2.0; ID 1 // появилась новая позиция с новым ID, но сделок в позиции нет, все сделки относятся с предыдущей позиции, поэтому комиссии и свопы 0.0
IN; +0.2; ID 1 // в списке появилась первая сделка и она единственная в списке
таким образом часть объема не перешла в новую позицию и нигде не отображена, соответственно не будет учтены свопы и комиссии по этой части объёма в позиции ID 1 (синее и зелёное соответствующие списки сделок)
Теперь как вижу я, как должно бы быть по логике и исторической очерёдности (какое решение примет MQ остаётся только догадываться):
IN; +1.0; ID 0
IN; +0.2; ID 0
OUT; -1.2; ID 0 // часть объёма сделки ушедшая на закрытие позиции
IN; -0.8; ID 1 // появилась новая позиция с новым ID, присутствует сделка как остаток, сделка есть в списке и она первая
IN; +0.2; ID 1 // вторая сделка в списке
Таким образом тип сделки IN/Out не нужен вообще. При таком способе учитывается всё коректно и списки сделок в позициях полные, адекватно можно получить значения комиссий и свопов по соответствующим сделкам. А если возникнет необходимость определить, какие сделки (одна часть пошла на закрытие а другая на открытие новой позиции) являются частью одного ордера, то определить это очень просто - сделки OUT и IN имеющие одинаковое время (выделено жирным).
На мой взгляд наоборот, не расширить перечисление нужно, а сократить. Так DEAL_ENTRY_INOUT это лишняя сущность, которая ничего не даёт.
Сделка - это сущность исполнения, никак не зависящая от платформы. А ENTRY-флаги - это MQ-придумка.
Если на рынке была одна сделка, то нельзя ее представлять, как две, пусть это и будет удобно.
MQ пошли на встречу, добавив виртуализацию - Hedge-режим. Делать даже простую виртуализацию для биржи - плохое решение.
А вот расширение свойств сделки дает удобство без потенциальных костылей.
Сделка - это сущность исполнения, никак не зависящая от платформы. А ENTRY-флаги - это MQ-придумка.
Если на рынке была одна сделка, то нельзя ее представлять, как две, пусть это и будет удобно.
MQ пошли на встречу, добавив виртуализацию - Hedge-режим. Делать даже простую виртуализацию для биржи - плохое решение.
А вот расширение свойств сделки дает удобство без потенциальных костылей.
Ну я высказал просто своё мнение.
И какое расширение спасло бы положение? Всё равно нужно как то определять, какая часть сделки относится к старой позиции а какая к новой.
И какое расширение спасло бы положение? Всё равно нужно как то определять, какая часть сделки относится к старой позиции а какая к новой.
1491 - Alpari-MT5-Demo. На скринах одно и то же место
Терминал
Тестер по реальным тикам
Свечи не соответствуют друг другу - в тестере пушистые. Более того, историческое время тестера и терминала отличаются на час.
CopyTicks в терминале возвращает данные, как в тестере - на час разницы. Поэтому тики полностью не соответствуют барам.
Ну и как верить MT5, тестеру, когда идет полная само-дискредитация? Почему у разработчиков нет эталонных проверочных советников, чтобы запустить в тестере и точно знать, что он отрабатывает четко? Полный бардак.