OrderSend() Вопросы - страница 8

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

Пока ожидаем статью на эту тему, правильно я понимаю общую концепцию анализа торговой операции.

...
bool AllowTrade = true;
ulong OrderTicket;
...
void OnTick() {
  ...
  if (!AllowTrade) return;
  ...
  MqlTradeResult Result;
  if (OrderSend(...)) {
    Ticket = Result.order;
    AllowTrade = false;
  }
}
...
void OnTrade() {
  if (AllowTrade) return;
  if (OrderSelect(Ticket)) {
    if (...)
    ...
    // AllowTrade = true|false;
  }
  else AllowTrade = true;
}
...

Т.е. грубо говоря, после отправки ордера, не анализируя реткод, запрещаем в рабочем цикле (OnTick()) торговые операции с помощью флага "AllowTrade".

Разблокирование запрета на торговлю происходит только в OnTrade() после поиска ордера по его номеру и некого анализа его судьбы.

Возникает два вопроса:

1. На какой предмет необходимо проверить тикет ордера в ОнТрейд? Какие статусы являются финальными в его жизни? 

2. Знаю, что очередь Tick-событий (OnTick) может "дропаться". Т.е. если приходит очередное событие Tick, а функция OnTick (от предыдущего тика) ещё не закончила свою работы, текущее событие "дропается", т.е. его обработки не произойдёт. Существует ли такой же подход с Trade-событиями (OnTrade)? Т.е. существует ли вероятность того, что, например, в основном цикле я выставлю запрет на торговлю, а событие OnTrade по только что отправленному ордеру "дропнется", т.к. на момент его прихода я ещё что-то буду продолжать обрабатывать в том же тике, что и отправка соответствующего торгового приказа?

 
voix_kas: Т.е. существует ли вероятность того, что, например, в основном цикле я выставлю запрет на торговлю, а событие OnTrade по только что отправленному ордеру "дропнется", т.к. на момент его прихода я ещё что-то буду продолжать обрабатывать в том же тике, что и отправка соответствующего торгового приказа?

 С этой темой не разбирался, но вот что говорится в Справочнике:

1) Длина очереди транзакций составляет 1024 элемента. В случае, если OnTradeTransaction() будет обрабатывать очередную транзакцию слишком долго, старые транзакции в очереди могут быть вытеснены более новыми;

2) OnTrade вызывается после соответствующих вызовов OnTradeTransaction.  

 
Yedelkin:

 С этой темой не разбирался, но вот что говорится в Справочнике:

1) Длина очереди транзакций составляет 1024 элемента. В случае, если OnTradeTransaction() будет обрабатывать очередную транзакцию слишком долго, старые транзакции в очереди могут быть вытеснены более новыми;

2) OnTrade вызывается после соответствующих вызовов OnTradeTransaction.  

В общем и целом понятно. Как уже указал papaklass и сказано в статье https://www.mql5.com/ru/articles/232:

Есть только один гарантированный способ выяснить, что именно изменилось на торговом счета. Этот способ - запоминать состояние торговли и торговой истории и сравнивать новое состояние с сохраненным.

Ещё одним служебным блоком в советнике больше. :(

 

Собственно, вопрос в чём... а можно ли в рамках уменьшение размеров кода не анализировать все переменные (ордера/сделки/позиции), а ориентироваться только лишь на ордер, номер которого получен из результата ОрдерСенда? Или этот номер может быть неуникален/не отражен в истории?

 
voix_kas: а можно ли в рамках уменьшение размеров кода не анализировать все переменные (ордера/сделки/позиции), а ориентироваться только лишь на ордер, номер которого получен из результата ОрдерСенда? Или этот номер может быть неуникален/не отражен в истории?

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

Вот, смотрите, как используется тикет ордера в истории: Справочник MQL5 / Торговые функции / HistoryOrderGetInteger  

 
Yedelkin:
 Конечно. Если в результате отправки торгового запроса удалось получить тикет ордера, то этот тикет является уникальным, и по нему можно отслеживать всю судьбу ордера.
Просто для инфо. В случае, если приказ не был принят сервером на исполнение, например, реквота, переменной MqlTradeResult Result.order присваивается какое-либо значение по-умолчанию (например, "0")?
 
voix_kas: В случае, если приказ не был принят сервером на исполнение, например, реквота, переменной MqlTradeResult Result.order присваивается какое-либо значение по-умолчанию (например, "0")?
Перед использованием переменной типа MqlTradeResult она обычно обнуляется. Так что поле Result.order содержит нулевое значение. Никогда не встречал, чтобы после неудачной отправки торгового запроса это поле принимало иное значение.
Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Yedelkin:
Перед использованием переменной типа MqlTradeResult она обычно обнуляется. Так что поле Result.order содержит нулевое значение. Никогда не встречал, чтобы после неудачной отправки торгового запроса это поле принимало иное значение.
Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6: 1. TRADE_RETCODE_PLACED Предположим, отложники не выставляем. Возможен ли такой ответ при торговле по рынку (SYMBOL_TRADE_EXECUTION_MARKET)? 2. TRADE_RETCODE_DONE Дальше можно ничего не перепроверять. Всё прошло именно так, как требовал советник. 3. TRADE_RETCODE_DONE_PARTIAL Как я полагаю, если мы торгуем не отложниками, данный ответ аналогичен TRADE_RETCODE_DONE с учётом режима ORDER_FILLING_IOC. 4. TRADE_RETCODE_ORDER_CHANGED Это означает однозначное отклонение нашего торгового приказа? 5. TRADE_RETCODE_LOCKED Полагаю, самый тяжкий случай. Как поступать в данном случае? Полагаю, номера ордера ещё нет. Торговый поток занят. Нельзя ни торговать, и непонятно, как узнать о разблокировании торгового потока. 6. TRADE_RETCODE_FROZEN Это означает однозначное отклонение нашего торгового приказа? Прокомментируйте, пожалуйста, по каждому пункту.
 

voix_kas: Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:  

1. TRADE_RETCODE_PLACED Предположим, отложники не выставляем. Возможен ли такой ответ при торговле по рынку (SYMBOL_TRADE_EXECUTION_MARKET)?

2. TRADE_RETCODE_DONE Дальше можно ничего не перепроверять. Всё прошло именно так, как требовал советник.

3. TRADE_RETCODE_DONE_PARTIAL Как я полагаю, если мы торгуем не отложниками, данный ответ аналогичен TRADE_RETCODE_DONE с учётом режима ORDER_FILLING_IOC.

4. TRADE_RETCODE_ORDER_CHANGED Это означает однозначное отклонение нашего торгового приказа?

5. TRADE_RETCODE_LOCKED Полагаю, самый тяжкий случай. Как поступать в данном случае? Полагаю, номера ордера ещё нет. Торговый поток занят. Нельзя ни торговать, и непонятно, как узнать о разблокировании торгового потока.

6. TRADE_RETCODE_FROZEN Это означает однозначное отклонение нашего торгового приказа?

Прокомментируйте, пожалуйста, по каждому пункту.

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

1. На форуме как-то упоминалась ситуация, при которой торговый счёт может быть открыт у субброкера. Вот в этом случае субброкер может отправить торговый запрос на обработку дальше (брокеру), а  в клиентский терминал послать TRADE_RETCODE_PLACED. Обработает ли в итоге брокер такой торговый запрос - заранее неизвестно.

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

3. Думаю, что речь идёт о частичном исполнении торгового запроса при режимах ORDER_FILLING_IOC и ORDER_FILLING_RETURN.

4.  https://www.mql5.com/ru/forum/1111/page124#comment_18407

5. Про этот код совершенно ничего не знаю. Формально получается, что запрос по  каким-либо внутренним причинам брокера не был обработан. Будет ли он обработан впоследствии - не понятно. Сам приравниваю этот код к отклонению торгового запроса.

6.  https://www.mql5.com/ru/forum/1111/page123#comment_18372

..А вообще - попробуйте форумный поиск по ключевым словам. Можно найти гораздо больше информации :)  

 
Yedelkin:

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

1. На форуме как-то упоминалась ситуация, при которой торговый счёт может быть открыт у субброкера. Вот в этом случае субброкер может отправить торговый запрос на обработку дальше (брокеру), а  в клиентский терминал послать TRADE_RETCODE_PLACED. Обработает ли в итоге брокер такой торговый запрос - заранее неизвестно.

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

3. Думаю, что речь идёт о частичном исполнении торгового запроса при режимах ORDER_FILLING_IOC и ORDER_FILLING_RETURN.

4.  https://www.mql5.com/ru/forum/1111/page124#comment_18407

5. Про этот код совершенно ничего не знаю. Формально получается, что запрос по  каким-либо внутренним причинам брокера не был обработан. Будет ли он обработан впоследствии - не понятно. Сам приравниваю этот код к отклонению торгового запроса.

6.  https://www.mql5.com/ru/forum/1111/page123#comment_18372

..А вообще - попробуйте форумный поиск по ключевым словам. Можно найти гораздо больше информации :)  

Итого имеем следующее, из 30 кодов 26 (включая TRADE_RETCODE_ORDER_CHANGED и TRADE_RETCODE_FROZEN) - однозначное отлонение запроса (не порождает ордер).

TRADE_RETCODE_DONE и TRADE_RETCODE_DONE_PARTIAL - гарантированно созданный ордер.

Как корректно отрабатывать TRADE_RETCODE_PLACED (не отложники) и TRADE_RETCODE_LOCKED - вопрос. Было бы признателен MQ за комментарии по этим двум кодам.

 
Это круто, всех с Новым годом #2015, но интересно, чем всё закончилось. Уже 2 года молчите...
123456789
Новый комментарий
Причина обращения: