![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Обратим внимание, Петр, как я реализовал мультиградиент из 6 цветов.
где p меняется от 0 до 1
ЗЫ правда там есть один недочет с крайним цветом, который еще руки не дошли исправить.
Очень оригинально. ) р - это произвольное пользовательское число, или оно связано с каким то параметром?
А это зачем?
p=p*5;
Можно же сразу нужное число послать. После этой строки р уже не возвращается к исходному значению.
Здесь:
можно записать:
и почему не используешь вместо
int n=MathRound(p);
?
Функция ARGB - штатная функция ССanvas, или твоя?
ЗЫ правда там есть один недочет с крайним цветом, который еще руки не дошли исправить.
Исправил:
Код, который выше подправил.
Функция ARGB - штатная функция ССanvas, или твоя?
ARGB - это дэфайн из CCanvas. Чтобы узнать, нажимаешь указатель мыши по имени и нажимаешь Alt+G
А это зачем?
5 - это количество цветов -1
и почему не используешь вместо
ARGB - это дэфайн из CCanvas. Чтобы узнать, нажимаешь указатель мыши по имени и нажимаешь Alt+G
5 - это количество цветов -1
Ок. Я не критиковал, просто спросил. Ты классно умеешь работать с цветом.
Ты классно умеешь работать с цветом.
Согласен. Но есть категория пользователей, которым нужно иначе.
А если возвращаемых данных канвасного индикатора будет больше 512 ? Тут буферы уже не помогут. А пользователи хотят просто получать данные от индикаторов в своих программах. И они не хотят их встраивать в тело советника (сову пожалею - пусть летает без погремушек в ...). И они хотят получать данные на любом запрашиваемом баре, а не только на видимых. И это оправдано. И оправдано не только ленью и желанием получать всё легко и просто, но и требованиями ТС.
если речь идет о подавляющем большинстве пользователей, которые не явлются программистами, то пользователям нужны или сова или индикатор. Им не нужен индикатор для совы.
Я лишь дал информацию для размышления, ничего не навязывая. Пусть программисты сами решают, что им комильфо, а что не комильфо. Но лично я после осознания некоторых моментов уже вряд ли буду использовать в своих советниках функцию iCustom.
Пожалуй я не совсем прав.
Совершенно логично предположить, что пользователь, купив или скачав такой канвасный безбуферный индикатор с маркета, захочет воспользоваться его данными в своем советнике.
Тогда самым разумным мне видится наладить обмен через специально созданную производителем этого индикатора структуру, которая считывается через ресурс.
Программисту, таким образом, нужно позаботиться в своем канвасном безбуферном индикаторе о том, чтобы эта структура постоянно держалась в ресурсе в актуальном состоянии и предоставить пользователю инклуд-файл, в котором бы эта структура бы считывалась используя пользовательские события или с приходом каждого тика (таймер использовать, мне кажется, будет не разумно).
А пользователю бы тогда нужно только в своем советнике включить одну только строчку кода #include... и тогда эта структура была бы всегда под рукой с актуальными данными из индикатора.
Мне видится это даже более удобным, чем классическое использование iCustom, т.к. структура может содержать удобно именованные переменные и массивы данных различных типов (а не тольков типа double как в буферах классического индикатора) и пользователю не нужно будет заморачиваться с тем, какой номер буфера что означает и ему достаточно включить лишь одну строчку кода в свою программу, чтобы иметь полный удобный доступ к данным индикатора.
ЗЫ Тем более я почти уверен что ресурсы у MQ реализованы практически так же, как и буферы индикатора.
Пожалуй я не совсем прав.
Совершенно логично предположить, что пользователь, купив или скачав такой канвасный индикатор с маркета, захочет воспользоваться его данными в своем советнике.
Тогда самым разумным мне видится наладить обмен через специально созданную производителем этого индикатора структуру, которая считывается через ресурс.
Программисту, таким образом, нужно позаботиться в своем канвасном безбуферном индикаторе о том, чтобы эта структура постоянно держалась в ресурсе в актуальном состоянии и предоставить пользователю инклуд-файл, в котором бы эта структура бы считывалась используя пользовательские события.
А пользователю бы тогда нужно только в своем советнике включить одну только строчку кода #include... и тогда эта структура была бы всегда под рукой с актуальными данными из индикатора.
Мне видится это даже более удобным, чем классическое использование iCustom, т.к. структура может содержать удобно именованные переменные и массивы данных и пользователю не нужно будет заморачиваться с тем, какой номер буфера что означает и ему достаточно включить лишь одну строчку кода в свою программу, чтобы иметь полный удобный доступ к данным индикатора.
ЗЫ Тем более я почти уверен что ресурсы у MQ реализованы практически так же, как и буферы индикатора.
Сам механизм передачи данных через ресурс крайне прост. Тут дело скорее в методе "общения" между двумя программами. Одна программа пишет, другая читает. Следовательно, программа которая пишет свои данные (индикатор) в ресурс, должна придерживаться заданного формата сообщения, а программа, которая читает, должна "знать" этот формат. Тогда общение между программами будет универсальным и эффективным.
Сам механизм передачи данных через ресурс крайне прост. Тут дело скорее в методе "общения" между двумя программами. Одна программа пишет, другая читает. Следовательно, программа которая пишет свои данные (индикатор) в ресурс, должна быть придерживаться формата сообщения, а программа, которая читает, должна "знать" этот формат. Тогда это общение будет универсальным и применимым.
Ну конечно, так и будет. Ведь приемную и передающую часть делает только один разработчик, который сам разработал данный индикатор.
Механизм обмена через ресурс не так уж прост. Это требует определенных навыков. В этом тоже мне видится преимущество данного способа, т.к. это будет превилегией более продвинутых программистов.
ЗЫ Петр, еще месяц назад тебе не казалось, что это это крайне просто и необходимо. Радует, что ты услышал и внял мой посыл. :))
Ну конечно, так и будет. Ведь приемную и передающую часть делает только один разработчик, который сам разработал данный индикатор.
Механизм обмена через ресурс не так уж прост. Это требует определенных навыков. В этом тоже мне видится преимущество данного способа, т.к. это будет превилегией более продвинутых программистов.
ЗЫ Петр, еще месяц назад тебе не казалось, что это это крайне просто и необходимо. Радует, что ты услышал и внял мой посыл. :))
Да, Николай, ресурсы оказались очень эффективным методом обмена данными между программами, а их использование базируется на юнионах, о которых ты мне говорил (и Василий тоже). Так что, вам обоим спасибо.)
Сам механизм перевода данных в ресурс и чтение их из него, достаточно простой, но формат сообщений - дело сложное, если стремиться к универсальности. Если решить вопрос для одного конкретного индикатора, то все просто.