Последовательность выполнение Init() и DeInit() - страница 17
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Получается, что Сервисы будут иметь почти все On-функции: OnInit, OnDeinit, OnTick(string), OnTimer, OnTrade, OnTradeTransaction, OnTester, OnTesterInit, OnTesterPass, OnTesterDeinit, OnBookEvent, OnChartEvent(long ChartID, ...), OnCalculate, ...
И если не нужны индикаторные буферы и не хочешь сталкиваться с костылями индикаторов/советников, то пиши в не страдающем (тянущимися из предыдущих версий MT) ограничениями новом виде программ - Сервисы.
Именно так.
OnCalculate не будет.
С OnChartEvent пока нет решения
Именно так.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Не получается брать данные индикатора со старшего ТФ
Sergey Dzyublik, 2017.04.14 10:55
У пользователя был индикатор измеряющий "силу" рынка.
Индикатор работал по текущему ТФ и валютной паре.
Задача была - показать результаты из 8 популярных валют на одном чарте с возможностью выбора независимого TФ для отображения.
На каком бы пользователь ТФ не был - должно показывать результат с установленного в параметры.
Проблему по прогрузке трафика с других валют по нужному ТФ решал следующим костылем:
где:
symbols_load - список валют необходимых прогрузить
Suffix - возможная приставка к названию валютных пар
TF - необходимый таймфрейм
Возможно ли добавить подписку/отписку на исторические данные (бары и тики) на заданный объем? Чтобы всегда был кеш (свежих баров и тиков) определенного размера у Сервиса для заданных символов.
Насколько же проще было бы тогда писать, например, скринеры рынка.
Индикаторы нужно использовать по прямому назначению.
Иными словами, очерёдность выполнения OnInit и OnDeinit индикатора при смене символа-периода графика не должна никого волновать
Такой подход многое объясняет.
Значит надо это принять как есть, главное знать об этом.
Нет.
Ещё раз перечитайте, что такое индикаторы. У Акелиса. У Колби. Да у яндекса спросите, что такое индикаторы рынка.
В MT3, когда мы ввели понятие кастомных индикаторов, мы позволили оперировать с объектами на графиках из-за того, что индикаторных буфера было всего 2.
Небольшой экскурс в историю. Сначала был FXCharts, я его не застал, так как пришёл в компанию всего лишь в октябре 2002 года. Потом был MetaTrader. Я пришёл в компанию на разработку MQL II (в FXCharts уже был язык торговых стратегий). Когда мы сделали MQL II и эксперты, мы поменяли название на MetaTrader 2. Когда мы дали возможность писать кастомные индикаторы, MetaTrader стал третьим - MetaTrader 3.
Потом был MetaTrader 4 и MQL4. Кастомные индикаторы получили возможность оперировать с 8 индикаторными буферами. Возможность работы с объектами на графике осталась. Но так как индикаторы рассчитывались в интерфейсном потоке, мало кто злоупотреблял работой с объектами.
И вот MT5. Архитектура совсем другая, но мы оказались заложниками MT4 в плане возможностей оперирования графическими объектами на чарте. Да мы - стахановцы, мы ещё, как герои, добавили практически неограниченные возможности управления графиком из индикаторов. Мы приехали. Иллюстрация - 16 страниц обсуждений ни о чём.
Будем переходить на сервисы
Папка Services в редакторе MQL5 появилась, но как использовать это инструмент еще не ясно. https://www.mql5.com/ru/forum/190129
Индикаторы нужно использовать по прямому назначению.
Иными словами, очерёдность выполнения OnInit и OnDeinit индикатора при смене символа-периода графика не должна никого волновать
А почему вся аргументация скатилась на графические объекты? Есть другие глобальные ресурсы вроде глобальных переменных, файлов и пр. (они в индикаторах по назначению могут применяться?), которые будут источником ошибок, если "очерёдность выполнения OnInit и OnDeinit индикатора при смене символа-периода графика не будет никого волновать". Еще раз обращаю внимание, что сейчас ядро реализовано так, что очередность должна волновать MQL-программиста, чтобы обходить грабли, вызванные неопределенностью последовательности вызовов инит/деинит. Чтобы не волновать MQL, нужно ядро, которое внутри позаботится о разрешении неопределенности.
Чем Сервисы или возможность запуска нескольких советников на одном чарте не смогут покрыть полностью обсуждаемые траблы?
Представьте, что вместо упомянутых в ветке случаев индикаторов будет запускаться Сервис, в котором будет лежать полностью расчетная часть индикатора. И он будет накидывать индикатор на чарт, который будет визуализировать посчитанные Сервисом данные в индикаторных буферах.
Индикаторы использовать по назначению нужно, а не делать из них что-то универсальное только лишь по той причине, что только индикаторы можно запускать по несколько штук на одном чарте. Так можно начать сетовать и на запрет OrderSend в индикаторах.
Чем Сервисы или возможность запуска нескольких советников на одном чарте не смогут покрыть полностью обсуждаемые траблы?
Представьте, что вместо упомянутых в ветке случаев индикаторов будет запускаться Сервис, в котором будет лежать полностью расчетная часть индикатора. И он будет накидывать индикатор на чарт, который будет визуализировать посчитанные Сервисом данные в индикаторных буферах.
Т.е. посредством сервиса можно будет создать индикатор?
Это и сейчас из советника можно (с некоторыми ограничениями).