Правильная установка ордеров. мт5 - страница 2

 
Михаил:

2. Не нужно делать лишнюю операцию OrderCheck()

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

 

А вот это: result.request_id == req_id то что мне и было нужно, связать в одно целое OrderSendAsync и OnTradeTransaction, как то сам просмотрел этот момент и анализировал получаемые сообщения последовательно, поэтому и не заметил этой связи.

Теперь значит я могу создать массив result.request_id и связав их с получаемыми req_id узнаю номер ордера в истории и смогу отследить установлен он или нет. По крайней мере при срабатывании OnTradeTransaction проблем с учётом ордеров не будет.

Благодарю! 

 
Вдруг стало интересно, но новую тему создавать не целесообразно: А разработчики что-нибудь говорят о том, что событие OnTradeTransaction не гарантированно. Как и чем они это объясняют ?
 
Alexey Oreshkin:
Вдруг стало интересно, но новую тему создавать не целесообразно: А разработчики что-нибудь говорят о том, что событие OnTradeTransaction не гарантированно. Как и чем они это объясняют ?

Они ничем это не объясняют.

Но, думаю, что это особенность Plaza II, через который работает МТ5

Не следует пугаться, что это событие не гарантировано(прочтите мой блог)

На деле оно не приходит 1 раз в два месяца при очень активной торговле.

 
Alexey Oreshkin:
Вдруг стало интересно, но новую тему создавать не целесообразно: А разработчики что-нибудь говорят о том, что событие OnTradeTransaction не гарантированно. Как и чем они это объясняют ?

Из документации на OnTradeTransaction:

....очередность поступления этих транзакций в терминал не гарантирована, поэтому нельзя свой торговый алгоритм строить на ожидании поступления одних торговых транзакций после прихода других. Кроме того, транзакции могут потеряться при доставке от сервера к терминалу.


На ФОРТСе бывает очень большой поток тиков. Так что совершенно простейший код вызывает критический сбой. Пример:

https://www.mql5.com/ru/forum/1111/page1239#comment_1120920

Прикол заключается в том, что никакими API нельзя запрашивать кол-во баров в истории инструмента на каждом тике (слава Богу и не надо).

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

API в таком случае возвращает невнятную ошибку 4001 (Неожиданная внутренняя ошибка), а в журнале терминала появляется ещё более странная запись вида "HistoryBase... 1 invalid bars removed".

Почему? Да просто запросы на каждом тике забивают весь канал связи =)

Причина обращения: