MT4: Нюанс OrderClose - отставание в обновлении таблицы закрытых позиций

Новый комментарий
 

Код:

if (OrderClose(....))
{
  Sleep(1000);
  OrderSelect(OrdersHistoryTotal() - 1, SELECT_BY_POS, MODE_HISTORY);
}

иногда даже с таким Sleep-ом OrderSelect не находит только что закрытую позицию. При этом за время работы Sleep никаких больше торговых операций не осуществляется (срабатывание отложек и т.д.).

Думал побороть проблему такой существуенной паузой, - стало лучше, чем без нее, но все равно проблема проскакивает. Увеличивать паузу не хочется, т.к. тормозится весь советник.

У кого какие мысли по обходу проблемы?

 
getch >>:

Код:

иногда даже с таким Sleep-ом OrderSelect не находит только что закрытую позицию. При этом за время работы Sleep никаких больше торговых операций не осуществляется (срабатывание отложек и т.д.).

Думал побороть проблему такой существуенной паузой, - стало лучше, чем без нее, но все равно проблема проскакивает. Увеличивать паузу не хочется, т.к. тормозится весь советник.

У кого какие мысли по обходу проблемы?


есть подозрение, что список ордеров обновляется с приходом тика.

попробуйте вместо Sleep() завершить функцию start() и получать данные о ордерах в ее начале.

 
Swan >>:

есть подозрение, что список ордеров обновляется с приходом тика.

попробуйте вместо Sleep() завершить функцию start() и получать данные о ордерах в ее начале.

Спасибо за предложение. Дело в том, что для мультивалютного советника это невозможно.

 
getch >>:

Попробовать RefreshRates() -- мало ли.

Попробовать выбирать по тикету. Вряд ли он меняется.

 
TheXpert >>:

Попробовать RefreshRates() -- мало ли.

Попробовать выбирать по тикету. Вряд ли он меняется.

RefreshRates() не помогает.

По тикету не стал выбирать, т.к. меняется.

Проблема в том, что на некоторых брокерах реализован механизм частичного исполнения (partial fills). По этой причине OrderClose (как и OrderSend по маркету) возвращает FALSE если даже было закрытие (открытие), но не на весь указанный объем. GetLastError() в таких ситуациях возвращают "off quotes", "common error" и т.д.

Получается, что на MQL4 OrderClose завершается с ошибкой, но на самом деле сделка закрывается частично (или полностью - зависит от реализации ECN-бриджа). Поэтому по тикету это определить нельзя. Вот и встал вопрос, как понять НАДЕЖНО (и быстро), что OrderClose сработал хотя бы частично.

 
последний закрытый ордер - не обязательно последний в списке.... вы повремени закрыти фильтровать не пробовали???
 
xrust >>:
последний закрытый ордер - не обязательно последний в списке.... вы повремени закрыти фильтровать не пробовали???

На месте разработчиков я бы так не делал. Т.к. всегда проще добавлять в конец, чем в середину.

Это предположение будет верно, если при настройках All History OrdersHistoryTotal() будет расти после вызова OrderClose.

Спасибо, попробую.

 
getch писал(а) >>

На месте разработчиков я бы так не делал. Т.к. всегда проще добавлять в конец, чем в середину.

Это предположение будет верно, если при настройках All History OrdersHistoryTotal() будет расти после вызова OrderClose.

Спасибо, попробую.

На самом деле массив ордеров один. Просто используем фильтр, закрытия ордера тикет не меняется. А присваивается он при открытии.

 
getch писал(а) >>

RefreshRates() не помогает.

По тикету не стал выбирать, т.к. меняется.

Проблема в том, что на некоторых брокерах реализован механизм частичного исполнения (partial fills). По этой причине OrderClose (как и OrderSend по маркету) возвращает FALSE если даже было закрытие (открытие), но не на весь указанный объем. GetLastError() в таких ситуациях возвращают "off quotes", "common error" и т.д.

Но, ведь как раз в историю попадает старый тикет.

 
Vinin >>:

На самом деле массив ордеров один. Просто используем фильтр, закрытия ордера тикет не меняется. А присваивается он при открытии.

Вы и Roger ошибаетесь, поскольку могли не видеть реализацию MT4-ECN-бриджей, где есть понятие Partial Fills.

Разработчики подобных бриджей вынуждены были немного изменить озвученное правило сохранения тикета из-за таких вот рыночных (не кухонных) обстоятельств нехватки ликвидности.

Можно убедиться воочию, попробовав один из подобных терминалов.

 
xrust >>:
последний закрытый ордер - не обязательно последний в списке.... вы повремени закрыти фильтровать не пробовали???

Попробовал, фильтр не дает результатов. Т.к. после OrderClose может дольше секунды обновляться таблица ордеров с количеством записей на одну больше. Более того, наблюдал, следующую ситуацию:

1. OrderClose

2. OrdersHistoryTotal не изменился.

3. OrderClose (другой тикет)

4. OrdersHistoryTotal увеличился на 2.

123
Новый комментарий
Причина обращения: