![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как по мне, проще создать команду по разработке продукта, члены которой в оговоренной степени получат профит от продаж продукта (возможно кто-то идеолог проекта, кто-то финансирует за долю, кто-то программит).
Ну и так как все материально мотивированы - реализовать в рамках проекта и нужные библиотеки для интерфейса.
Как по мне, проще создать команду по разработке продукта, члены которой в оговоренной степени получат профит от продаж продукта (возможно кто-то идеолог проекта, кто-то финансирует за долю, кто-то программит).
Ну и так как все материально мотивированы - реализовать в рамках проекта и нужные библиотеки для интерфейса.
Почитал я ветку и так и не понял, зачем это нужно - рисовать кнопку на Canvas с нуля. Можете объяснить без эмоций?
так как разрабы МТ не всесильны и напрягать их мелочными хотелками дорого по времени
Зачем это может пригодиться:
1. Интерфейс на битмапе быстрый. Настолько быстрый, что он практически неотличим от системного. Например, я реализовал полупрозрачные элементы с градиентами и даже при их движении они без видимых задержек плавно отрисовываются с учетом смешения цветов и расчета альфа канала на других объектах с полупрозрачными градиентами.
2. Интерфейс масштабируемый. Можно усложнять приложение и оно не будет замедляться по причине удаления и создания большого количества граф. объектов. Расходы на перерисовку минимальные, это всего лишь замена картинки, за тысячные доли секунды.
3. Можно создать готовые контролы и обеспечить возможность создать новые т.к. можно предусмотреть собственный пул событий, например:
OnMouseDown - нажали ЛКМ
OnMouseUp - отжали ЛКМ
OnMouseHoverOn - навели курсор мыши на объект
OnMouseHoverOut - отвели курсор мыши с объекта
OnMouseClick - нажали и отжали ЛКМ в границах объекта воздействия
OnMouseDblClick двойной клик ЛКМ в границах объекта воздействия
OnDragStart - событие возникающее 1 раз в начале движения с нажатой ЛКМ
OnDragMove - событие генерящееся в процессе движения С ЛКМ
OnDragEnd - событие генерящееся после движения с ЛКМ
OnPut - объект скинули на другой объект
OnGet - объекту кинули другой объект
OnFocus - объект получил фокус
OnBlur - объект потерял фокус
OnResize - у объекта изменился размер
OnParentResize - у родителя объекта изменился размер
OnKeyPress - произошло нажатие клавиши
OnChange - изменилось значение поля
и т.д.
Зачем это может пригодиться:
1. Интерфейс на битмапе быстрый. Настолько быстрый, что он практически неотличим от системного. Например, я реализовал полупрозрачные элементы с градиентами и даже при их движении они без видимых задержек плавно отрисовываются с учетом смешения цветов и расчета альфа канала на других объектах с полупрозрачными градиентами.
2. Интерфейс масштабируемый. Можно усложнять приложение и оно не будет замедляться по причине удаления и создания большого количества граф. объектов. Расходы на перерисовку минимальные, это всего лишь замена картинки, за тысячные доли секунды.
3. Можно создать готовые контролы и обеспечить возможность создать новые т.к. можно предусмотреть собственный пул событий, например:
OnMouseDown - нажали ЛКМ
OnMouseUp - отжали ЛКМ
OnMouseHoverOn - навели курсор мыши на объект
OnMouseHoverOut - отвели курсор мыши с объекта
OnMouseClick - нажали и отжали ЛКМ в границах объекта воздействия
OnMouseDblClick двойной клик ЛКМ в границах объекта воздействия
OnDragStart - событие возникающее 1 раз в начале движения с нажатой ЛКМ
OnDragMove - событие генерящееся в процессе движения С ЛКМ
OnDragEnd - событие генерящееся после движения с ЛКМ
OnPut - объект скинули на другой объект
OnGet - объекту кинули другой объект
OnFocus - объект получил фокус
OnBlur - объект потерял фокус
OnResize - у объекта изменился размер
OnParentResize - у родителя объекта изменился размер
OnKeyPress - произошло нажатие клавиши
OnChange - изменилось значение поля
и т.д.
Исчерпывающе, спасибо!
@Igor Volodin, @Комбинатор, @Anatoli Kazharski
ну тогда начну с наболевшего )
Вопрос, который меня больше всего волнует - некая универсальность/абстракция для хранения параметров отрисовки.
----
как мы понимаем все контролы в равной мере используют шрифт, цвет фона и цвет текста и т.д.
Когда все эти параметры одинаковы для всех контролов, то интерфейс имеет общий вид с единым концептом.
Но как их хранить? ведь контролы не всегда используют все параметры.
+ система усложняется тем, что у элементов есть различные состояния, которые должны по разному использовать цвета шрифта и фона. А именно когда элемент Активный, когда не реагирует на мышь (Disable), когда мышка над объектом (Over), или когда контрол отмечен (Select). и т.д.
+ есть группы контролов - рельефиные (типа Button) и поля ввода (типа Edit, List), и когда это фон для их отрисовки
----
В текущей рабочей идее у меня есть минимальный элемент атрибута class GAttribBase, в котором находятся 5 основных параметров (шрифт/размер, цвет фона/бордюра, размер бордюра)
Из этих базовых элементов формируется массив для состояний class GAttribut, в котором задаются эти параметры для состояний (Active/Disabvle/Over/Select и т.д.)
И вот уже GAttribut заполняется для разных типов элементов - для рельефных, для редатируемых и т.д.
таким образом мы заполняем параметры отрисовок один раз (храним в xml), их можно живо редатировать чтоб создавать разные дизайны и используем их глобально, не определяя их для каждого контрола.
Конечно, если у некоего контрола нужно определить свои параметры отрисовки - то достаточно создать в контроле свой объект GAttribut и уточнить нужные цвета.
----
Данная модель рабочая, единый дизайн достигается в два счёта, все контролы берут цвета из общего массива.
Но на мой взгляд она не универсальна. Так как юзеру не прозрачен тот факт какие именно параметры из базового GAttribBase используются для отрисовки того или иного контрола.
Чтоб кодеру точно знать какой цвет надо поменять - ему придется смотреть в функцию отрисовки контрола. Что напряжно.
-----
Вобщем - какие есть идеи, чтоб с одной стороны кодер был свободен от работы с цветами (чтоб он сразу использовал заложенные цвета и не заморачивался на них в начале)
А с другой стороны - чтоб если он захотел перекрасить какой-то один контрол на экране - то не влазил в дебри функции отрисовки и не выискивал что же из GAttribBase юзается и в каком случае.
@Igor Volodin, @Комбинатор, @Anatoli Kazharski
Вобщем - какие есть идеи, чтоб с одной стороны кодер был свободен от работы с цветами (чтоб он сразу использовал заложенные цвета и не заморачивался на них в начале)
А с другой стороны - чтоб если он захотел перекрасить какой-то один контрол на экране - то не влазил в дебри функции отрисовки и не выискивал что же из GAttribBase юзается и в каком случае.
Хорошо, темы.
Например, главный объект нашего приложения, назовем его App, ассоциирован с объектом ConcreteTheme.
Что такое объект темы:
цвета (background, foreground, disable, active и т.д.), базовые размеры, размеры шрифтов для стандартных случаев: titlesize, commonsize и т.д. , спрайты для: панелей, кнопок, чекбоксов и т.д.
Новая тема - новый класс/структура с измененными значениями. Но лучше чтобы темы можно было наследовать, перекрывая только определенные параметры.
Остальное - иерархия контролов в который каждый контрол использует по-умолчанию одно из необходимых ему значений объекта-темы. Если необходимо перекрыть - вызовем метод работы с этим свойством, с указанием нового значения.
Например SetBgColor(XRGB(255,0,128));
CView - основной класс обеспечивающий базовое взаимодействие на уровне событий
- СRect - координаты
- СPanel имеет bgcolor
- CButton имеет объект состояния, у каждого состояния указывается bg
- CText имеет цвет текста и свойства шрифта
- СCircle
И т.д.
Если есть желание использовать xml для описания элементов,
то для каждого класса контрола или примитива нужно создать порождающий класс назовем его "билд-контейнер" в котором будут маппиться атрибуты (bgcolor="(255,0,128)") на соответствующие методы ( SetBgColor(attrValue) ) класса. Такие билд-контейнеры будут цепляться парсером XML, на выходе получаем проинициализированный нужными значениями объект контрола, либо дефолтными, если ничего не было указано.
тут Theme то же самое что у меня - набор GAttribut под разные типы контролов и их состояния.
но вы уже предлагаете первый шаг на пути к прозрачности для кодера - добавляем функции в конкретный контрол для изменения его свойств отрисовки (SetBgColor и т.д.)
В принципе согласен, будет понятно какие цвета он имеет и что можно менять.
такой вопрос тогда - Theme подразумевает избыточность неиспользуемых параметров?
Допустим что у меня в базовом GAttribBase для некоего контрола (например кнопки) мы используем только цвет фона и размер, а остальные параметры - толщина границы и т.д. не используется в этом контроле.
То есть - у вас имеется базовый элемент для всех контролов? где хранится инфа "на все случаи", или же все контролы имеют только свои параметры без оферхеда универсальности?
...
Вобщем - какие есть идеи, чтоб с одной стороны кодер был свободен от работы с цветами (чтоб он сразу использовал заложенные цвета и не заморачивался на них в начале)
А с другой стороны - чтоб если он захотел перекрасить какой-то один контрол на экране - то не влазил в дебри функции отрисовки и не выискивал что же из GAttribBase юзается и в каком случае.
Задать для каждого элемента значения по умолчанию. Если пользователю нужно что-то изменить, то для каждого свойства элемента должен быть метод для установки нового значения. Это так сейчас у меня сделано.
Вот этого ещё пока нет:
Но всё это моё рассуждение относительно моей схемы. Не исключаю, что она ещё очень сильно изменится, когда я начну переход на новый этап. Поэтому всё, что написал выше, может быть уже неактуально в рамках обсуждаемой здесь темы. )