Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну Вы же смысл поняли. Рассказываю дотошно на память, можете проверить: Функция OrderSend() возвращает булево значение. При этом в случае удачной проверки запроса в переменную структуры MqlResult записывается тикет ордера. Для себя я это называю "возвращение функцией тикета ордера". Вот ссылка на источник: "При отправке запроса на покупку функцией OrderSend() можно сразу же узнать тикет ордера, который был создан при успешном результате проверки запроса".
А если уж отвлекаться от темы по инициативе модератора - то держите аналогичный ответ: учебника по MQL5 нет и не предвидится, так что непонятно, в какой учебник Вы сами заглядываете. ...Может, либо по существу обсуждать, либо вообще никак? :)
За ответ про "запрет" - спасибо, понял.
Не совсем правильное понимание того что происходит при получении ответа от сервера.
OrderSend() дейсвтвительно возвращает булевое значение, но это не самое главное, главным является структура которая заполняется при получении ответа от сервера.
Да, действительно в структуру записывается тикет (не только ордера но и сделки), но разве он важней остальной информации в структуре?
Рассмотрим структуру ответа. На мой взгляд картинка примерно следующая
PS
Структуру правильней называть MqlTradeResult, а не MqlResult (хотя не сильно важно на мой взгляд).
Если запрос корректен и выполнен то volume и price важны в том случае если сервер "имел право" урезать данные параметры сделки и может потребоваться реакция со стороны эксперта на действия сервера.
к сожалению до сих пор не уловил.
вам зачем-то нужно в структуре возврата иметь поле "время". Используйте время в появившемся ордере. Этого достаточно для контроля небольшой истории.
Структуру правильней называть MqlTradeResult, а не MqlResult (хотя не сильно важно на мой взгляд).
Не совсем правильное понимание того что происходит при получении ответа от сервера.
OrderSend() дейсвтвительно возвращает булевое значение, но это не самое главное, главным является структура которая заполняется при получении ответа от сервера.
Да, действительно в структуру записывается тикет (не только ордера но и сделки), но разве он важней остальной информации в структуре?
"При отправке запроса на покупку функцией OrderSend() можно сразу же узнать тикет ордера, который был создан при успешном результате проверки запроса. Но в то же время сам ордер еще может не появиться в клиентском терминале и попытка выбрать его с помощью функции OrderSelect окажется неуспешной". Из второго предложения следует, что далеко не всегда можно поработать со свойствами ордера (временем ордера), даже если известен его тикет. Поэтому "использовать время в появившемся ордере" - это не идеальное решение. Кроме того, ордер может вообще "не открыться". Мой подход решил бы проблему контроля небольшой истории независимо от того, что происходило с ордером до его попадания в историю.
Ну не знаю, если это так важно попросите разработчиков внести дополнения в структуру MqlTradeResult (в виде времени на которое сделка выполнена или ордер установлен).
Хотя я не понимаю зачем это нужно, лучше уж параметры добавить в OnTrade().
Ну не знаю, если это так важно попросите разработчиков внести дополнения в структуру MqlTradeResult (в виде времени на которое сделка выполнена или ордер установлен).
Дык, я об этом и спрашивал с самого начала :) Был ли прецедент, так сказать :)
Дополнение. Если бы кто-то такой вопрос поднимал бы с полгода назад, можно было бы ещё надеяться на относительно скорое появление фичи, а ждать следующего года - проще самому ввести переменную для даты. Хоть будет и не совсем точно, но всё-таки.
Хотя я не понимаю зачем это нужно, лучше уж параметры добавить в OnTrade().
Я лично уже не могу больше ждать, когда появится структура/параметры Trade. И так уже 9 месяцев ждал. Приходится выкручиваться из того, что есть.
Я "по памяти" писал, в ответ на совет изучать учебник Ну, не будем спорить, у кого правильнее понимание :) Посмотрите мой ответ Сергееву. А здесь повторюсь: мне по логике стратегии нужен только тикет и время принятия ордера к производству. Подчёркнутое Вами не является ни тем, ни другим. "Очень важная информация", такая как retcode совершенно не помогает оптимизировать закачку истории, о чём я в общем-то веду речь.
1. OrderSend() и закачка истории, а вот с этого места по подробней (а то что-то не доганяю о чем речь, да и трава кажись кончилась).
2. По логике вещей если анализ ведется только по результату OrderSend() порядок действий таков
а) Проверяем retcode, нужно же знать что на самом деле произошло;
б) если результат успешный получаем Тикет, объем и цену. Если реквота то получаем новые цены (проверяем при этом насколько они нас устроят)
в) если ответ нас устроил и ошибок нет получаем тикет и время. Время можно взять серверное или попытаться вытащить его из истории (для приблизительных расчетов на данный момент удобней узнать серверное время);
г) Если нас не устраивает ответ (или устраивает лишь от части) - не совпадает объем или мы получили реквоту принимаем решение о следующих действиях.
PS
Короче, как не крути, а retcode поо хорошему нужно посмотреть.
что-то не доганяю о чем речь, да и трава кажись кончилась).
Посмотрите ход обсуждения с самого начала. ...Значимость retcode никто не отрицает, но при простых решениях вполне можно обойтись без него.
на сколько для вас критичен предложенный вариант?
в) если ответ нас устроил и ошибок нет получаем тикет. Время можно взять текущее;
на сколько для вас критичен предложенный вариант?
Это стандартный вариант (который имеет свои минусы, указанные выше) + самостоятельное сохранение времени. Так как проверка retcode у меня не требуется, то остаётся только вопрос про сохранение времени: либо самостоятельно, либо эстетично с помощью MqlTradeResult. Собственно, в связи с этим и возник вопрос :)
Если запрос успешно выполнен сделка рано или поздно попадет в историю, а ордер появится в списке. Следовательно там и можно будет точно узнать что и как.
А предложенный вариант это так сказать "на скорую руку", для тех кто сразу хочет примерно получить все данные которые нужны и не мучится лишними действиями.
Конечно возможно стоит добавить еще что-то в ответ сервера, но тут есть ряд особенностей и причин по которым разработчики могут не согласиться с таким вариантом (да и просьба, уж извените мало обоснована и подтверждена убедительными доводами).
PS
Хотя, я может быть что-то упустил и разработчики решать что она вполне целесообразна.