OrderSendAsync не возвращает номер тикета (OnTradeTransaction - ловля блох или асинхронных хаос? ) - страница 3

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

Я усложнил задачу. Открытие трёх позиций асинхронно по трём валютам.

void OnTick()
 {
  if(countPos == 0)
   {
    string symb[] = {"EURUSD", "GBPUSD", "USDJPY"};
    for(int i = 0; i < 3; i++)
     {
      double ask = SymbolInfoDouble(symb[i], SYMBOL_BID),
             point = SymbolInfoDouble(symb[i], SYMBOL_POINT);
      int digits = (int)SymbolInfoInteger(symb[i], SYMBOL_DIGITS);
      Print(trade.PositionOpen(symb[i], ORDER_TYPE_SELL, 0.1, ask, NormalizeDouble(ask+400*point, digits), NormalizeDouble(ask-400*point, digits)));
     }
   }
 }

2020.03.18 16:34:55.287 2019.12.23 00:00:30   trans.type - TRADE_TRANSACTION_REQUEST
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.retcode = 10009
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.order = 2
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.deal = 2
2020.03.18 16:34:55.287 2019.12.23 00:00:30   position = 2
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.magic = 3
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.symbol = EURUSD
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.type = ORDER_TYPE_SELL
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.volume = 0.1
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.price = 1.1075
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.sl = 1.1115
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.tp = 1.1035
2020.03.18 16:34:55.287 2019.12.23 00:00:30   trans.type - TRADE_TRANSACTION_REQUEST
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.retcode = 10009
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.order = 3
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.deal = 3
2020.03.18 16:34:55.287 2019.12.23 00:00:30   position = 3
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.magic = 3
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.symbol = GBPUSD
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.type = ORDER_TYPE_SELL
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.volume = 0.1
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.price = 1.2994
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.sl = 1.3034
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.tp = 1.2954
2020.03.18 16:34:55.287 2019.12.23 00:00:30   trans.type - TRADE_TRANSACTION_REQUEST
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.retcode = 10009
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.order = 4
2020.03.18 16:34:55.287 2019.12.23 00:00:30   result.deal = 4
2020.03.18 16:34:55.287 2019.12.23 00:00:30   position = 4
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.magic = 3
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.symbol = USDJPY
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.type = ORDER_TYPE_SELL
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.volume = 0.1
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.price = 109.428
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.sl = 109.828
2020.03.18 16:34:55.287 2019.12.23 00:00:30   request.tp = 109.028
 
Vladimir Belozercev:


Благодарю, что хватило сил прочесть до конца ))

Вы просто не умеете пользоваться описанными Вами функциями.

Здесь https://www.mql5.com/ru/forum/38456/page136#comment_15425184 (прикрепленные файлы)

рабочий код. Там все предельно ясно.

Откройте демо счет ФОРТС (фьючерсы) в Открытии или БКС и посмотрите, как нужно пользоваться функциями.

Добавлено

Если ничего не приходит в OnTradeTransaction (в коде этого нет)

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

Если есть ордер, то ищем по ордеру, если нет ордера, то ищем по уникальному magic. 

Принцип - каждому ордеру присваивается уникальный magic, по которому 

идет проверка что произошло с ордером (в коде есть "ошметки" как это делается mem_time - для проверки интервала времени, mem_start_time - для поиска ордера в узком отрезке времени,

magic_storage - для хранения текущего magic). Automagic.mqh позволяет генерить уникальный начальный magic для символа и советника,

позволяющий хранить 254 magic

ФОРТС. Вопросы по исполнению
ФОРТС. Вопросы по исполнению
  • 2020.03.13
  • www.mql5.com
С большими проблемами удалось это сделать (начальник отдела по работе с профессиональными клиентами ДЦ Открытие Евгений Сергеевич,.
 
Vladimir Belozercev:

Да хранение - не проблема. Это все есть. Проблема как раз в привязке (см. временную диаграмму выше).

  1. Функция OrderSendAsync не возвращает ТИКЕТ в 70-80% случаев;
  2. Функция OrderSendAsync гарантированно (я надеюсь) возвращает только request_id;
  3. Транзакции торгового исполнения (первые 4-ре) можно привязать только по ТИКЕТУ;
  4. А ТИКЕТ появляется в конце, когда уже торговое исполнение прошло...

На мой взгляд, как бы я реализовал требуемый функционал.
1. Для каждого источника сигнала создал бы свою структуру для хранения данных по сделкам.
2. Для каждой заявки генерировал бы уникальный меджик и сохранял его в соответствующей сигналу структуре. 
3. Не ждал бы возврата от OrderSendAsync после отправки заявки. А искал бы тикет ордера в OnTradeTransaction по уникальному меджику.
4. После получения тикета не проблема идентифицировать все сделки, связанные с данным ордером.

В качестве примера прилагаю лог реальных транзакций.
Жирным зеленым цветом выделял для себя значимые данные, которые требуется анализировать.
Красным цветом выделены данные не несущие полезной информациии. 

Файлы:
Transactions.zip  20 kb
 
Vasiliy Sokolov:

Вы не первый. Почитайте посты Михаила. Он много об этом писал здесь несколько лет назад. Ему вроде попробовали отвечать разрабы, но поезд и ныне там. И он кстати тоже использует асинхронную отправку заявок.

Василий, спасибо, почитал... Отрадно что не я один спотыкаюсь об это, но печально что движения нет со стороны разработчиков. Хотя я их понимаю. Людей, которые обращаются к асинхронной модели - единицы...

 
fxsaber:

Не испытывал совсем проблем с OrderSend. Возможно, по причине отсутствия MOEX.

Но если бы нужен был OrderSendAsync, то не использовал бы OnTradeTransaction, а воспользовался бы подобным решением.

За месяц до этого трэда я тоже не испытывал... Но когда OrderSend стали зависать по минуте, а потом возвращаются еще и с ошибкой, решил сделать шаг в сторону асинхронной модели (уж коль 9 и 10-ти шагов уже было сделано, ну или я так думал).

Отличный код, как всегда, в прочем... Спасибо. Хотя это и псевдо-асинхронная модель из-за использования OnTimer, если быть дотошным, что, на мой взгляд, немного избыточно, но зато универсально (будет работать и на МТ4). В остальном, наши с Вами мысли совпадают (я планировал использовать связанный список, поскольку fifo тут и не пахло). Поскольку у меня нет задачи обеспечить мульти-платформенность, а ограничивают событиями OnTradeTransaction и OnTick, хотя я думаю что первичным источником событий всегда выступает OnTick.

По своей невнимательности не увидел, что разработчики MT, как впрочем и все мы, пытаются минимизировать трудозатраты. В результате ответа, как такового, на request нет. Они сразу пытаются его исполнить, поэтому сначала идут "Транзакции торгового исполнения", и лишь в конце цепочки, сразу кучей, отправляют ответ и на request и на result, из-за чего один хрен придется ждать TRADE_TRANSACTION_REQUEST, что возвращает нас, практически, к функциональности OrderSend.

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

В любом случае, спасибо. Было весьма познавательно и полезно )).

 
Alexey Viktorov:

Ну я не понимаю в чём трудности.

Вот код советника

И вот результат выполнения на счёте Netting.

Никаких трудностей с получением тикета позиции не вижу.

Алексей, вы же понимаете, если написать 10 раз "я не понимаю в чём трудности" то это не приблизит Вас к пониманию?.. Я Вам уже временную диаграмму нарисовал с ключами первичной идентификации. Даже не знаю, что я могу Вам написать, чтобы помочь с пониманием...

Ведь речь не о невозможности обработать эту ситуацию, а об усложнении обработки из-за упрощений, которые использовали разработчики МТ5 при реализации асинхронки, выродив асинхронную модель в ту же синхронную...

Постараюсь еще раз пояснить... Ответа, как такового, на request нет. Сервер сразу пытаются его исполнить, поэтому сначала идут "Транзакции торгового исполнения", и лишь в конце цепочки, сразу кучей, отправляют ответ и на request и на result, из-за чего один хрен придется ждать ФИНАЛИЗИРУЮЩЕЙ транзакции - TRADE_TRANSACTION_REQUEST, что возвращает нас, практически, к функциональности OrderSend.

Что касается приведенного Вами кода, то он хуже, чем использование OrderSend, и вот почему:

  1. Вы все равно дожидаетесь ФИНАЛИЗИРУЮЩЕЙ транзакции - TRADE_TRANSACTION_REQUEST, что собственно и делает OrderSend;
  2. Но кроме этого вы еще нагружаете эксперт дополнительным двойным вызовом поиска через HistoryOrder*** для получения тикета сделки, что OrderSend сделает это гораздо быстрее.
  3. Ну и я не большой сторонник использования функций HistoryХХХХХ. При большой динамике торговых транзакций они начинают ощутимо притормаживать.

Согласитесь, что было бы гораздо эффективнее сначала получить ответ на запрос, в котором вы могли бы обработать ошибки размещения, и в случае успеха, поймать транзакцию TRADE_TRANSACTION_DEAL_ADD, что подтвердило бы вывод сделки в рынок, но...

Вместо этого мы с вами видим не идентифицированные торговые транзакции (ТТ) и ничего не можем с ними сделать до тех пор пока, в ФИНАЛИЗИРУЮЩЕЙ транзакции - TRADE_TRANSACTION_REQUEST, не получим данные по их (ТТ) идентификации. И поскольку нет системы сквозной идентификации транзакций, или хотя бы разделением ответов requet/result - асинхронке "грошь цена"...

 
Vladimir Belozercev:


Вы смотрели код, который я вам порекомендовал?

 
Vladimir Mikhailov:

На мой взгляд, как бы я реализовал требуемый функционал.
1. Для каждого источника сигнала создал бы свою структуру для хранения данных по сделкам.
2. Для каждой заявки генерировал бы уникальный меджик и сохранял его в соответствующей сигналу структуре. 
3. Не ждал бы возврата от OrderSendAsync после отправки заявки. А искал бы тикет ордера в OnTradeTransaction по уникальному меджику.
4. После получения тикета не проблема идентифицировать все сделки, связанные с данным ордером.

В качестве примера прилагаю лог реальных транзакций.
Жирным зеленым цветом выделял для себя значимые данные, которые требуется анализировать.
Красным цветом выделены данные не несущие полезной информациии. 

Владимир, это так не работает. Поясню попунктно...
  1. Это очевидные вещи. Предлагаю на них не заострять внимание...
  2. Мэджик не решает проблематики идентификации транзакций при их текущей очередности. Мэджик появляется только ФИНАЛИЗИРУЮЩЕЙ транзакции - TRADE_TRANSACTION_REQUEST.
  3. Не очень понял что Вы имели ввиду. OrderSendAsync ждать невозможно. Он отправляет request и тут же возвращает управление. торговые транзакции (ТТ) не имеют признака меджика - только тикет сделки.
  4. Именно в этом и проблема, что без тикета сквозная идентификация невозможна... Связь между запросом и ТТ вы получите в финальной TRADE_TRANSACTION_REQUEST
Даже в Вашем же файле всю эту проблематику прекрасно видно... Он правда не очень подробный, но даже там это очевидно. Сначала идут ТТ и финализируются структурами request/result, где и содержаться первичные идентификационные параметры


Ниже привожу блок транзакций, относящихся к открытию одной позиции. Первая часть - это ТТ, второй блок - финальная TRADE_TRANSACTION_REQUEST. Все расположено в хронологическом порядке.

А теперь прошу, найдите в серии ТТ идентификационный признак, о котором вы говорите?! А я скажу, что кроме тикета сделки и ордера (а их связь с вашим запросом появится только в финальной TRADE_TRANSACTION_REQUEST) вы ничего там не найдете.

Все, что у вас есть на момент окончания работы OrderSendAsync - Request ID. И где же он?! А он в финальной TRADE_TRANSACTION_REQUEST.

2020.03.20 19:28:51 (Srv 14:28:50)        ( 0-0)     TRADE_TRANSACTION_ORDER_ADD / DEAL_TYPE_BUY: ------------Transaction :
Transaction: TRADE_TRANSACTION_ORDER_ADD
Symbol: EURUSD
Deal ticket: 0
Deal type: DEAL_TYPE_BUY
Order ticket: 550689914
Order type: ORDER_TYPE_SELL
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 1.0731
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 0.01
Position: 0
Position by: 0

2020.03.20 19:28:51 (Srv 14:28:50)        ( 0-0)     TRADE_TRANSACTION_DEAL_ADD / DEAL_TYPE_SELL: ------------Transaction :
Transaction: TRADE_TRANSACTION_DEAL_ADD
Symbol: EURUSD
Deal ticket: 528476110
Deal type: DEAL_TYPE_SELL
Order ticket: 550689914
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 1.0731
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 0.01
Position: 550689914
Position by: 0

2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_DEAL_ADD / DEAL_TYPE_SELL: INFO: p=1 gp=1 #550689914 By=528476110 Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=0 TSyncCnt=1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_DEAL_ADD / DEAL_TYPE_SELL: WAITING TSync: #550689914 (by ps#0/or#550689914).   Info: #550689914: (p= 1-0 Mp= 30 ML= 70 MEph=  1 Mcfg=1 McfgDate=1548028800) Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=0 TSyncCnt=1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_DEAL_ADD / DEAL_TYPE_SELL: ОТКРЫТИЕ ордера: #550689914 (by ps#0/or#550689914) для позиции.    Info: #550689914: (p= 1-0 Mp= 30 ML= 70 MEph=  1 Mcfg=1 McfgDate=1548028800) Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=0 TSyncCnt=1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_DEAL_ADD / DEAL_TYPE_SELL: 
END: #550689914.
2020.03.20 19:28:51 (Srv 14:28:50)        ( 0-0)     TRADE_TRANSACTION_ORDER_DELETE / DEAL_TYPE_BUY: ------------Transaction :
Transaction: TRADE_TRANSACTION_ORDER_DELETE
Symbol: EURUSD
Deal ticket: 0
Deal type: DEAL_TYPE_BUY
Order ticket: 550689914
Order type: ORDER_TYPE_SELL
Order state: ORDER_STATE_FILLED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 1.0731
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 0
Position: 550689914
Position by: 0

2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_ORDER_DELETE / DEAL_TYPE_BUY: INFO: p=1 gp=1 #550689914 By=528476110 Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=1 TSyncCnt=-1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_ORDER_DELETE / DEAL_TYPE_BUY: ALREADY TSync: #550689914 (by ps#0/or#550689914).   Info: #550689914: (p= 1-0 Mp= 30 ML= 70 MEph=  1 Mcfg=1 McfgDate=1548028800) Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=1 TSyncCnt=-1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_ORDER_DELETE / DEAL_TYPE_BUY: ORDER_DELETE: Управляемое УДАЛЕНИЕ открытой позиции (TK): #550689914 (by ps#0/or#550689914).  Info: #550689914: (p= 1-0 Mp= 30 ML= 70 MEph=  1 Mcfg=1 McfgDate=1548028800) Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=1 TSyncCnt=-1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_ORDER_DELETE / DEAL_TYPE_BUY: TRADE_TRANSACTION_ORDER_DELETE: END
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_ORDER_DELETE / DEAL_TYPE_BUY: 
END: #550689914.
2020.03.20 19:28:51 (Srv 14:28:50)        ( 0-0)     TRADE_TRANSACTION_HISTORY_ADD / DEAL_TYPE_BUY: ------------Transaction :
Transaction: TRADE_TRANSACTION_HISTORY_ADD
Symbol: EURUSD
Deal ticket: 0
Deal type: DEAL_TYPE_BUY
Order ticket: 550689914
Order type: ORDER_TYPE_SELL
Order state: ORDER_STATE_FILLED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 1.0731
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 0
Position: 550689914
Position by: 0

2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_HISTORY_ADD / DEAL_TYPE_BUY: INFO: p=1 gp=1 #550689914 By=528476110 Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=1 TSyncCnt=-1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_HISTORY_ADD / DEAL_TYPE_BUY: ALREADY TSync: #550689914 (by ps#0/or#550689914).    Info: #550689914: (p= 1-0 Mp= 30 ML= 70 MEph=  1 Mcfg=1 McfgDate=1548028800) Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=1 TSyncCnt=-1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_HISTORY_ADD / DEAL_TYPE_BUY: TRADE_TRANSACTION_HISTORY_ADD: START
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_HISTORY_ADD / DEAL_TYPE_BUY: HISTORY: Управляемое УДАЛЕНИЕ открытой позиции (TK): #550689914 (by ps#0/or#550689914).  Info: #550689914: (p= 1-0 Mp= 30 ML= 70 MEph=  1 Mcfg=1 McfgDate=1548028800) Signal=TclACT/BUSY/SELLING/gl:TclACT/BUSY/SELLING LastT= Status=1 Active=0 Sync=1 TSync=1 TSyncCnt=-1
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_HISTORY_ADD / DEAL_TYPE_BUY: TRADE_TRANSACTION_HISTORY_ADD: END
2020.03.20 19:28:51 (Srv 14:28:50)        ( 1-0)     TRADE_TRANSACTION_HISTORY_ADD / DEAL_TYPE_BUY: 
END: #550689914.


Финальная TRADE_TRANSACTION_REQUEST. И вот, наконец, мы видем заветный Request ID, в связке с тикетами:

Request ID: 396
Order ticket: 550689914
Deal ticket: 528476110

И только теперь мы можем связать прошедшие ранее транзакции с нашим запросом:

2020.03.20 19:28:51 (Srv 14:28:50)        ( 0-0)     TRADE_TRANSACTION_REQUEST / DEAL_TYPE_BUY: TRADE_TRANSACTION_REQUEST
2020.03.20 19:28:51 (Srv 14:28:50)        ( 0-0)     TRADE_TRANSACTION_REQUEST / DEAL_TYPE_BUY: ------------Request  :
Request: TRADE_ACTION_DEAL
Symbol: EURUSD
Magic Number: 100030000107001
Order ticket: 550689914
Order type: ORDER_TYPE_SELL
Order filling: ORDER_FILLING_FOK
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 1.0731
Deviation points: 36
Stop Loss: 0
Take Profit: 0
Stop Limit: 0
Volume: 0.01
Comment: p=1-0 M= 30 L= 70 E= 1 c=1

2020.03.20 19:28:51 (Srv 14:28:50)        ( 0-0)     TRADE_TRANSACTION_REQUEST / DEAL_TYPE_BUY: ------------Result   :
TradeResult 10009 Desc=Заявка выполнена
Request ID: 396
Order ticket: 550689914
Deal ticket: 528476110
Volume: 0.01
Price: 1.0731
Ask: 1.07316
Bid: 1.0731
RetCode Ext: 0
Comment: 

2020.03.20 19:28:51 (Srv 14:28:50)        ( 0-0)     TRADE_TRANSACTION_REQUEST / DEAL_TYPE_BUY: ------------Transaction :
Transaction: TRADE_TRANSACTION_REQUEST
Symbol: 
Deal ticket: 0
Deal type: DEAL_TYPE_BUY
Order ticket: 0
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 0
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 0
Position: 0
Position by: 0
 
Vladimir Belozercev:

Все, что у вас есть на момент окончания работы OrderSendAsync - Request ID. И где же он?! А он в финальной TRADE_TRANSACTION_REQUEST.

А, простите, на кой дьявол вам requestID если в trans.type == TRADE_TRANSACTION_DEAL_ADD есть trans.position по которому можно проверить 

if(PositionSelectByTicket(trans.position) && trans.volume == заданному)

Если true значит requestID 10009 и другого быть не может. В противном случае получим в trans.type ==TRADE_TRANSACTION_REQUEST requestID и будем принимать решение.

Для отложенных ордеров решение другое.

Ну, если вы так бьётесь за пару миллисекунд, то я умолкаю...

Ещё обратите внимание на статьи Артёма Тришкина. У него есть решение лучше, но сложное для моего возраста.

 
Alexey Viktorov:

А, простите, на кой дьявол вам requestID ...

:)

А если отложенный ордер и исполнился не полным объемом?

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