![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
denkir!
Нельзя "зашить" ID в комментарий, потому что ID возвращает терминал(result), а комментарий в request!
У меня работает 50 экспертов, в день 2000 транзакций.
Советники не будут "вылезать" из истории :)
Ведь нет функции HistoryOrderSelectByMagic();
А разработчикам создать новую функцию не очень сложно и даже очень нужно!
Magic нужен на тот случай, если пропала "синхронизация", и это будут единичные случаи.
denkir!
Если разработчики дали OrderSend() и механизм его отслеживания,
то и должны были дать такой же механизм отслеживания для OrderSendAsync,
не заставляя своих пользователей из г-на шарики катать!
ID Придётся вести "сквозной", а не по генератору случайных чисел.
Кстати, мне больше нравится ваша идея писать в комментарий свой ID нежели манипуляции с magic.
denkir!
Если разработчики дали OrderSend() и механизм его отслеживания,
то и должны были дать такой же механизм отслеживания для OrderSendAsync,
не заставляя своих пользователей из г-на шарики катать!
ID Придётся вести "сквозной", а не по генератору случайных чисел.
Кстати, мне больше нравится ваша идея писать в комментарий ID нежели манипуляции с magic.
Mikalas, а id вообще удаётся получить? Я тут попробовал на ECN счёте поймать результат асинхронной отсылки... вот что вышло:
id возвращается - request_id=4, только интересный код - retcode = 10008.
Да, думаю, что MQ создавая тип MqlTradeResult, больше думали об OrderSend(), чем об OrderSendAsync().
Да и ещё механизм идентификации по id практически в MQL не развит, скорее по тикетам... такая вот концепция... г-но это или шарики из него, это вопрос риторический :-)
denkir!
Посылаем ордер:
Принимаем результат:
Но OnTradeTransaction не гарантировано приходит, поэтому нужен механизм поиска ордера.
...Но OnTradeTransaction не гарантировано приходит, поэтому нужен механизм поиска ордера.
Что значит негарантированно? Какие симптомы?
В хелпе написано, что не гарантируют приход этого события (потерялся, например).
Где искать request_id, если что-то случилось с OnTradeTransaction ( в истории этого идентификатора нет )?
Может быть разработчики введут скоро функцию:
OnTradeTransaction не может гарантировать контроль исполнения. Ответа сервера может не быть вовсе. Универсального способа работы в асинхронном режиме нет. Лично у меня работа в асинхронном режиме происходит с помощью сценариев. Сценарий - это некий класс, который содержит список мелких подзадач. Например что бы советнику со стоп-лосом закрыть часть своей позиции необходимо выполнить несколько операций: 1. Удалить свой отложенный стоп-ордер, выполняющий роль стоп-лосса, 2. выставить встречный объем для своей позиции и дождаться исполнения этой заявки. 3. Выставить новый стоп-ордер с новым объемом. Все эти подзадачи в виде списка находятся внутри сценария, его движок берет самое первое задание и запускает его на выполнение. Каждая из подзадач подписана на события OnTradeTrnsaction и OnTimer. После его запуска, сценарий проверяет статус его выполнения. Статус выполнения дает само задание, анализируя OnradeTransaction и обновляя окружение по OnTimer. Если задание выполнено, сценарий переходит к следующей задачи.
В этом случае HistoryOrderSelectById не нужен, т.к. каждый советник прекрасно знает на каком этапе сценария он находится и чем завершились предыдущие задачи. Более того, одновременно один советник может обрабатывать параллельно хоть сотню разных сценариев, потому что все они выполняются асинхронно и не требуют ожидания на свое выполнение.
Все это я к тому, что HistoryOrderBySelectById едва ли введут, и в принципе можно обойтись и без него, т.к. возможно написать надежное решение и без этой функции.
Дорогой C-4!
У вас просто не было случая, чтобы не сработал OnTradeTransaction,
Никакой сценарий вам не поможет, чтобы узнать что произошло с ордером.
И какой смысл использовать OrderSendAsync, если вы проверяете его на таймере?
У меня среднее исполнение приказов 45-50 мс, так какой интервал должен быть у таймера?
50 экспертов просто "повесят" процессор.