
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Видимо, так. Думаю, это связано с тем, что список и свойства ордеров постоянно изменяется и чтобы иметь актуальную информацию, надо выбирать ордер непосредственно перед работой с ним.
единственное остается загадкой, зачем было вносить поле m_ticket в класс COrderInfo (к тому же еще и неправильного типа long вместо ulong), если его нельзя редактировать, Но он же используется в функции PositionId.
return(HistoryOrderGetInteger(m_ticket,ORDER_POSITION_ID));
но задать m_ticket нет возможности. значит и функция бесполезна (как и само наличие поля).
Думаю, что разработчикам стоит внести хотябы функцию Select.
и поменять тип m_ticket.Все таки объект есть объект. А не просто набор функций для доступа к свойствам, что сейчас есть.
единственное остается загадкой, зачем было вносить поле m_ticket в класс COrderInfo (к тому же еще и неправильного типа long вместо ulong), если его нельзя редактировать, Но он же используется в функции PositionId.
return(HistoryOrderGetInteger(m_ticket,ORDER_POSITION_ID));
но задать m_ticket нет возможности. значит и функция бесполезна (как и само наличие поля).
Думаю, что разработчикам стоит внести хотябы функцию Select.
и поменять тип m_ticket.Все таки объект есть объект. А не просто набор функций для доступа к свойствам, что сейчас есть.
Обратите внимание: PositionId по тиккету выбирается из истории ордеров, а не из текущих рыночных и отложенных.
Для неисполненных ордеров вообще не существует PositionId. А для исторических ордеров есть HistoryOrderInfo.mqh.
Так, что лучше данный метод вообще удалить, а заодно и m_ticket.
Я уже исправил глюк разработчиков в моей версии класса COrderInfo. Ввел два метода:
Только опираться на это решение пока не могу, т.к. нет поддержки разработчиков.
В документации должно быть указано, что перед работой с классами необходимо вручную выбирать нужный тикет, либо устанавливать нужный тикет с помощью метода Ticket, ничего этого нет.
Вот еще одна путаница: читаю документацию к функции OrderSelect:
Выбирает ордер для дальнейшей работы с ним. Возвращает true при успешном завершении функции. Возвращает false при неудачном завершении функции. Чтобы получить информацию об ошибке, необходимо вызвать функцию GetLastError().
Теперь читаю доку к HystoryOrderSelect():
HistoryOrderSelect
Выбирает в истории ордер для последующих обращений к нему через соответствующие функции. Возвращает true при успешном завершении функции. Возвращает false при неудачном завершении функции. Чтобы получить информацию об ошибке, необходимо вызвать функцию GetLastError().
Значит ли это что функция OrderSelect не может выбирать ордер из истории? В документации к ней ничего об этом не сказано. Если ордер выбрать из истории можно, тогда зачем нужна функция HistoryOrderSelect?
Обратите внимание: PositionId по тиккету выбирается из истории ордеров, а не из текущих рыночных и отложенных.
Для неисполненных ордеров вообще не существует PositionId. А для исторических ордеров есть HistoryOrderInfo.mqh.
Конечно. Ведь отложенные ордера не участвуют в позиции. Только тогда, когда ордер инициализируется сделкой (т.е. входом к конкретную позицию), только тогда можно говорить о связи ордера и позиции.
Я уже исправил глюк разработчиков в моей версии класса COrderInfo. Ввел два метода:
Только опираться на это решение пока не могу, т.к. нет поддержки разработчиков.
В документации должно быть указано, что перед работой с классами необходимо вручную выбирать нужный тикет, либо устанавливать нужный тикет с помощью метода Ticket, ничего этого нет.
Вот еще одна путаница: читаю документацию к функции OrderSelect:
Теперь читаю доку к HystoryOrderSelect():
Значит ли это что функция OrderSelect не может выбирать ордер из истории? В документации к ней ничего об этом не сказано. Если ордер выбрать из истории можно, тогда зачем нужна функция HistoryOrderSelect?
Конечно не может. Выбирает только из отложенных и установленных, но неисполненных рыночных. А вот для истории - только HistoryOrderSelect.
Можно, конечно, доопределить файлы стандартной библиотеки, но поместить их надо в другое место, иначе при очередном обновлении библиотеки старые файлы востановятся и у Вас не будут работать программы, использующие вновь определённые методы. Я уже с этим сталкивался. И как тогда общаться с другими пользователями при обмене программами ? Везде необходимо прикладывать свой вариант.
Нет, стандартная библиотека потому и стандартная, что она едина для всех пользователей и при её использовании в программах не возникает разночтений.
Нет, стандартная библиотека потому и стандартная, что она едина для всех пользователей и при её использовании в программах не возникает разночтений.
Я про это же и говорю: "Опираться на это решение не могу, т.к. нет поддержки разработчиков". Единственный вариант долбиться в сервисдеск и писать разработчикам в чем они не правы.
Я про это же и говорю: "Опираться на это решение не могу, т.к. нет поддержки разработчиков". Единственный вариант долбиться в сервисдеск и писать разработчикам в чем они не правы.
Ведь классы планировались не за одну минуту, а значит есть на то причины их такому использованию. Хотя лучше бы конечно добавить эти две функции.
М.б. последние изменения не попали в билд. Файл с исправлениями. Спасибо. Извините.
Но и данной редакции установить m_ticket невозможно. Тогда с чем работать будем ?
PS. А нашёл, в функции bool COrderInfo::Select(ulong ticket)