Мт4 Конец поддержке. - страница 19

 
Alexey Viktorov:

Совет от самонедоучки:

Чтобы легче было переходить на mql5 уже сейчас в mql4 желательно использовать не int переменные периода а из перечисления ENUM_TIMEFRAMES

Задачу решу по своему. Главное - функция должна работать хорошо и не тормозить программу и использоваться на обоих терминалах. Остальное оставьте на мое усмотрение.
 
Dmitry Fedoseev:

Зачем?


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

А еще туда можно базу данных запихать, потом еще некоторый софт, и все свое таскать с собой в 1 иконке
 
Alexander Puzanov:

С радостью верю что ваши задачи без них не решить. Чтобы не поверить нужно вникать в подробности :)


Покрутите

Теперь на одном тике надо определить наступление нового бара Н1, М5 и D1. То-есть первые 1час 5 минут советник спит и только в 1:05 новых суток должен очухаться и что-то сделать.

Это будет 3 глобальных переменных? А если в 2-3-7 советниках надо сделать то-же самое? Ещё разновидности имён глобальных переменных плодить?

 
Реter Konow:
Задачу решу по своему. Главное - функция должна работать хорошо и не тормозить программу и использоваться на обоих терминалах. Остальное оставьте на мое усмотрение.

Вот это ваша проволочка в предоставлении решения, это уже красноречивый ответ. Потому-что с ООП задача решается просто и стандартно без каких-либо размышлений. 

 
Реter Konow:
Задачу решу по своему. Главное - функция должна работать хорошо и не тормозить программу и использоваться на обоих терминалах. Остальное оставьте на мое усмотрение.
Никто ничего не навязывает. Это было всего-лишь мнение.
 
Dmitry Fedoseev:

Вот это ваша проволочка в предоставлении решения, это уже красноречивый ответ. Потому-что с ООП задача решается просто и стандартно без каких-либо размышлений. 

Я трейдингом не занимаюсь, потому для меня эта задача нестандартна. Не мешайте.
 
Alexander Puzanov:

С радостью верю что ваши задачи без них не решить. Чтобы не поверить нужно вникать в подробности :)

Вот зачастую народ жалуется, что, мол, "работа с индикаторами на МТ5 гораздо сложнее, чем на МТ4.

Так вот, ООП-подход - позволяет унифицировать эту работу, чтобы советник, опять же, даже не интересовался, на какой платформе он работает.

У меня это организовано так.

Если нужен индикатор (скажем, МА) - советник должен объявить объект CMA_IParams:public CIndicatorParamsI, в котором записать все параметры МА, которые нужны. Затем, указатель на эту структуру передать Дата-провайдеру, в функцию   GetIndicator(). Эта функция вернет указатель на виртуальный интерфейс CIndicator. Все. В этом интерфейсе - есть все необходимые данные по вызванному индикатору.

Если требуется любой другой индикатор - опять же, объявляется объект-наследник интерфейса CIndicatorParamsI, в него записываются все параметры индикатора, и это передается в дата-провайдер, взамен возвращается указатель на созданный индикатор.

Когда требуется новый индикатор - его переносимый код записывается в дата-провайдере, после чего, опять же - любой пользователь может запрашивать у дата-провайдера новый индикатор, передав дата-провайдеру его параметры.

В результате - скажем, если эксперт работает "на возврат к среднему" - становится очень легко поменять это самое среднее, например, вместо МА взять середину Price Channel - чисто заменив объект параметров.

Интересно, как подобное организовано у любителей процедурного подхода ?

 
George Merts:

Вот зачастую народ жалуется, что, мол, "работа с индикаторами на МТ5 гораздо сложнее, чем на МТ4.

Так вот, ООП-подход - позволяет унифицировать эту работу, чтобы советник, опять же, даже не интересовался, на какой платформе он работает.

У меня это организовано так.

Если нужен индикатор (скажем, МА) - советник должен объявить объект CMA_IParams:public CIndicatorParamsI, в котором записать все параметры МА, которые нужны. Затем, указатель на эту структуру передать Дата-провадеру, в функцию   GetIndicator(). Эта функция вернет указатель на виртуальный интерфейс CIndicator. Все. в этом интерфейсе - есть все необходимые данные по вызванному индикатору.

Если требуется любой другой индикатор - опять же, объявляется объект-наследник интерфейса CIndicatorParamsI, в него записываются все параметры индикатора, и это передается в дата-провайдер, взамен возвращается указатель на созданный индикатор.

Когда требуется новый индикатор - его переносимый код записывается в дата-провайдере, после чего, опять же - любой пользователь может запрашивать у дата-провайдера новый индикатор, передав дата-провайдеру его параметры.

В результате - скажем, если эксперт работает "на возврат к среднему" - становится очень легко поменять это самое среднее, например, вместо МА взять середину Price Channel - чисто заменив объект параметров.

Интересно, как подобное организовано у любителей процедурного подхода ?

С этого лучше не начинать. Именно это и отпугивает. Даже я, сторонник ООП плохо его знающий от этого текста встал в ступор... ничего не понял. Поэтому стараюсь объяснить разницу на самом низком уровне.
 

Я извиняюсь, должен уехать. Поступил приказ... Если не возражаете продолжим завтра.

 
Alexey Viktorov:

Я извиняюсь, должен уехать. Поступил приказ... Если не возражаете продолжим завтра.

Дан приказ ему на запад?

Причина обращения: