Как найти идентификатор запроса? - страница 2

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

denkir!

Нельзя "зашить" ID в комментарий, потому что ID возвращает терминал(result), а комментарий в request! 

Это да... а свой ID разве не придумать? Можно для этого дела подтянуть генератор случайных чисел :-)
 
Mikalas:

У меня работает 50 экспертов, в день 2000 транзакций.

Советники не будут "вылезать" из истории :) 

Ведь нет функции HistoryOrderSelectByMagic(); 

А разработчикам создать новую функцию не очень сложно и даже очень нужно! 

Magic нужен на тот случай, если пропала "синхронизация", и это будут единичные случаи.

 

denkir!

Если разработчики дали OrderSend() и механизм его отслеживания,

то и должны были дать такой же механизм отслеживания для OrderSendAsync,

не заставляя своих пользователей из г-на шарики катать! 

ID Придётся вести "сквозной", а не по генератору случайных чисел.

Кстати, мне больше нравится ваша идея писать в комментарий свой ID нежели манипуляции с magic.

 
Mikalas:

denkir!

Если разработчики дали OrderSend() и механизм его отслеживания,

то и должны были дать такой же механизм отслеживания для OrderSendAsync,

не заставляя своих пользователей из г-на шарики катать! 

ID Придётся вести "сквозной", а не по генератору случайных чисел.

Кстати, мне больше нравится ваша идея писать в комментарий ID нежели манипуляции с magic.

Mikalas, а id вообще удаётся получить? Я тут попробовал на ECN счёте поймать результат асинхронной отсылки... вот что вышло:

id возвращается - request_id=4, только интересный код - retcode = 10008.

Да, думаю, что MQ создавая тип MqlTradeResult, больше думали об OrderSend(), чем об OrderSendAsync().

Да и ещё механизм идентификации по id практически в MQL не развит, скорее по тикетам... такая вот концепция... г-но это или шарики из него, это вопрос риторический :-)


 

denkir!

Посылаем ордер: 

if ( OrderSendAsync( request, result ) )
{
 if ( result.retcode == TRADE_RETCODE_PLACED ) 
 {
    order_id = result.request_id;
 }
}

 Принимаем результат:

void OnTradeTransaction( const MqlTradeTransaction &trans, const MqlTradeRequest &request, const MqlTradeResult &result )
{
  switch( trans.type )
  {
    case TRADE_TRANSACTION_REQUEST:      if ( ( order_id != 0 ) && ( result.request_id == order_id ) )
                                         {
                                           order_ticket = result.order;
                                         }
                                         break;
  }
}

 Но OnTradeTransaction не гарантировано приходит, поэтому нужен механизм поиска ордера.

 
Mikalas:


...Но OnTradeTransaction не гарантировано приходит, поэтому нужен механизм поиска ордера.

Что значит негарантированно? Какие симптомы?
 
denkir:
Что значит негарантированно? Какие симптомы?
В хелпе написано, что не гарантируют приход этого события (потерялся, например).
 
Mikalas:
В хелпе написано, что не гарантируют приход этого события (потерялся, например).
Ясно. Тогда проверки нужно делать... если не пришло, делать проверку по истории ордеров и сделок... но там id уже не поймаешь :-))
 
Mikalas:

Где искать request_id, если что-то случилось с OnTradeTransaction ( в истории этого идентификатора нет  )?

Может быть разработчики введут скоро функцию:

OnTradeTransaction не может гарантировать контроль исполнения. Ответа сервера может не быть вовсе. Универсального способа работы в асинхронном режиме нет. Лично у меня работа в асинхронном режиме происходит с помощью сценариев. Сценарий - это некий класс, который содержит список мелких подзадач. Например что бы советнику со стоп-лосом закрыть часть своей позиции необходимо выполнить несколько операций: 1. Удалить свой отложенный стоп-ордер, выполняющий роль стоп-лосса, 2. выставить встречный объем для своей позиции и дождаться исполнения этой заявки. 3. Выставить новый стоп-ордер с новым объемом. Все эти подзадачи в виде списка находятся внутри сценария, его движок берет самое первое задание и запускает его на выполнение. Каждая из подзадач подписана на события OnTradeTrnsaction и OnTimer. После его запуска, сценарий проверяет статус его выполнения. Статус выполнения дает само задание, анализируя OnradeTransaction и обновляя окружение по OnTimer. Если задание выполнено, сценарий переходит к следующей задачи.

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

Все это я к тому, что HistoryOrderBySelectById едва ли введут, и в принципе можно обойтись и без него, т.к. возможно написать надежное решение и без этой функции.

 

Дорогой C-4!

У вас просто не было случая, чтобы не сработал OnTradeTransaction,

Никакой сценарий вам не поможет, чтобы узнать что произошло с ордером. 

И какой смысл использовать OrderSendAsync, если вы проверяете его на таймере?

У меня среднее исполнение приказов 45-50 мс, так какой интервал должен быть у таймера? 

50 экспертов просто "повесят" процессор. 

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