Почему класс COrderInfo не позволяет выбирать ордер? - страница 3

 
Valmars:

Но и данной редакции установить m_ticket невозможно. Тогда с чем работать будем ?

PS. А нашёл, в функции bool COrderInfo::Select(ulong ticket)
 

uncleVic:
М.б. последние изменения не попали в билд. Файл с исправлениями. Спасибо. Извините.

Зачем классу COrderInfo новый метод Select?!!! Получается что в разных классах разные названия методов выполняющие одно и тоже. HistoryOrderInfo имеет прекрасно перегуженный метод Ticket(), который позволяет устанавливать и считывать тикет ордера. В OrderInfo уже два метода один считывает тикет - Ticket(), другой устанавливает тикет - Select(). Вместо этого, метод Ticket() можно было бы перегрузить и сделать аналогичную реализацию как в классе CHistoryOrderInfo.
Документация по MQL5: Торговые функции / OrderGetTicket
Документация по MQL5: Торговые функции / OrderGetTicket
  • www.mql5.com
Торговые функции / OrderGetTicket - Документация по MQL5
 
C-4:
Зачем классу COrderInfo новый метод Select?!!! Получается что в разных классах разные названия методов выполняющие одно и тоже. HistoryOrderInfo имеет прекрасно перегуженный метод Ticket(), который позволяет устанавливать и считывать тикет ордера. В OrderInfo уже два метода один считывает тикет - Ticket(), другой устанавливает тикет - Select(). Вместо этого, метод Ticket() можно было бы перегрузить и сделать аналогичную реализацию как в классе CHistoryOrderInfo.
Дело в том, что ОРДЕР и ИСТОРИЧЕСКИЙ ОРДЕР имеют разные механизма доступа к данным. ИСТОРИЧЕСКИЙ ОРДЕР отдает данные по тикету, а ОРДЕР после вызова функции

bool  OrderSelect(ulong ticket). Методы классив стандартной библиотеки "стараются" быть похожими на функции MQL5.

 
uncleVic:
Дело в том, что ОРДЕР и ИСТОРИЧЕСКИЙ ОРДЕР имеют разные механизма доступа к данным. ИСТОРИЧЕСКИЙ ОРДЕР отдает данные по тикету, а ОРДЕР после вызова функции

bool  OrderSelect(ulong ticket). Методы классив стандартной библиотеки "стараются" быть похожими на функции MQL5.

Вопрос не в этом. Просто перегрузите метод Ticket() подобным образом:

   void              Ticket(ulong ticket) { OrderSelect(ticket); m_ticket=ticket;  }
   ulong             Ticket() const       { return(m_ticket); }

 Т.е. то, что делает Select, может и должен делать Ticket(). Стандарты унификации это определяют.

 
C-4:

Вопрос не в этом. Просто перегрузите метод Ticket() подобным образом:

 Т.е. то, что делает Select, может и должен делать Ticket(). Стандарты унификации это определяют.

Тоже так думаю. Потому не нашел сразу Select(ulong ticket). Присвоили теккет, а потом с ним работаем.
 
C-4:

Вопрос не в этом. Просто перегрузите метод Ticket() подобным образом:

 Т.е. то, что делает Select, может и должен делать Ticket(). Стандарты унификации это определяют.

Она сделана по подобию как и PositionInfo. Стандарты унификации растут от понятий, а не результата.

Мне кажется "понятнее" слово Select. Так как при вызове Select - заменяются данные окружения, а просто Ticket - это не обязан делать (по смыслу).

тем более, что отдельного Select в DealInfo и в HistoryOrderInfo не нужно. все данные получаются по тикету. А в OrderInfo - совсем другая ситуация. Все базовые функции - не зависят от имеющегося m_ticket. В нем главное сделать предварительный OrderSelect !

И правильно сказано,

uncleVic:
...что ОРДЕР и ИСТОРИЧЕСКИЙ ОРДЕР имеют разные механизма доступа к данным. ИСТОРИЧЕСКИЙ ОРДЕР отдает данные по тикету, а ОРДЕР после вызова функции OrderSelect