Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Совет от самонедоучки:
Чтобы легче было переходить на mql5 уже сейчас в mql4 желательно использовать не int переменные периода а из перечисления ENUM_TIMEFRAMES
Зачем?
Затем что при реализации такой штуки через другие языки я затрудняюсь над тем как влезть в терминал. Открыть он сможет что угодно и все, а если это через мкл реализовать туда еще и ботов через кнопки потом позапихивать можно.
А еще туда можно базу данных запихать, потом еще некоторый софт, и все свое таскать с собой в 1 иконкеС радостью верю что ваши задачи без них не решить. Чтобы не поверить нужно вникать в подробности :)
Покрутите
Теперь на одном тике надо определить наступление нового бара Н1, М5 и D1. То-есть первые 1час 5 минут советник спит и только в 1:05 новых суток должен очухаться и что-то сделать.
Это будет 3 глобальных переменных? А если в 2-3-7 советниках надо сделать то-же самое? Ещё разновидности имён глобальных переменных плодить?
Задачу решу по своему. Главное - функция должна работать хорошо и не тормозить программу и использоваться на обоих терминалах. Остальное оставьте на мое усмотрение.
Вот это ваша проволочка в предоставлении решения, это уже красноречивый ответ. Потому-что с ООП задача решается просто и стандартно без каких-либо размышлений.
Задачу решу по своему. Главное - функция должна работать хорошо и не тормозить программу и использоваться на обоих терминалах. Остальное оставьте на мое усмотрение.
Вот это ваша проволочка в предоставлении решения, это уже красноречивый ответ. Потому-что с ООП задача решается просто и стандартно без каких-либо размышлений.
С радостью верю что ваши задачи без них не решить. Чтобы не поверить нужно вникать в подробности :)
Вот зачастую народ жалуется, что, мол, "работа с индикаторами на МТ5 гораздо сложнее, чем на МТ4.
Так вот, ООП-подход - позволяет унифицировать эту работу, чтобы советник, опять же, даже не интересовался, на какой платформе он работает.
У меня это организовано так.
Если нужен индикатор (скажем, МА) - советник должен объявить объект CMA_IParams:public CIndicatorParamsI, в котором записать все параметры МА, которые нужны. Затем, указатель на эту структуру передать Дата-провайдеру, в функцию GetIndicator(). Эта функция вернет указатель на виртуальный интерфейс CIndicator. Все. В этом интерфейсе - есть все необходимые данные по вызванному индикатору.
Если требуется любой другой индикатор - опять же, объявляется объект-наследник интерфейса CIndicatorParamsI, в него записываются все параметры индикатора, и это передается в дата-провайдер, взамен возвращается указатель на созданный индикатор.
Когда требуется новый индикатор - его переносимый код записывается в дата-провайдере, после чего, опять же - любой пользователь может запрашивать у дата-провайдера новый индикатор, передав дата-провайдеру его параметры.
В результате - скажем, если эксперт работает "на возврат к среднему" - становится очень легко поменять это самое среднее, например, вместо МА взять середину Price Channel - чисто заменив объект параметров.
Интересно, как подобное организовано у любителей процедурного подхода ?
Вот зачастую народ жалуется, что, мол, "работа с индикаторами на МТ5 гораздо сложнее, чем на МТ4.
Так вот, ООП-подход - позволяет унифицировать эту работу, чтобы советник, опять же, даже не интересовался, на какой платформе он работает.
У меня это организовано так.
Если нужен индикатор (скажем, МА) - советник должен объявить объект CMA_IParams:public CIndicatorParamsI, в котором записать все параметры МА, которые нужны. Затем, указатель на эту структуру передать Дата-провадеру, в функцию GetIndicator(). Эта функция вернет указатель на виртуальный интерфейс CIndicator. Все. в этом интерфейсе - есть все необходимые данные по вызванному индикатору.
Если требуется любой другой индикатор - опять же, объявляется объект-наследник интерфейса CIndicatorParamsI, в него записываются все параметры индикатора, и это передается в дата-провайдер, взамен возвращается указатель на созданный индикатор.
Когда требуется новый индикатор - его переносимый код записывается в дата-провайдере, после чего, опять же - любой пользователь может запрашивать у дата-провайдера новый индикатор, передав дата-провайдеру его параметры.
В результате - скажем, если эксперт работает "на возврат к среднему" - становится очень легко поменять это самое среднее, например, вместо МА взять середину Price Channel - чисто заменив объект параметров.
Интересно, как подобное организовано у любителей процедурного подхода ?
Я извиняюсь, должен уехать. Поступил приказ... Если не возражаете продолжим завтра.
Я извиняюсь, должен уехать. Поступил приказ... Если не возражаете продолжим завтра.
Дан приказ ему на запад?