Делаем краудсорсовый проект по Canvas - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
ElementSet, где нужно задать (1) свойство и значение или (2) свойство, модификатор и значение.
да, это универсально в рамках обращения к свойствам контрола.
вообще PropGet/Set - это хороший механизм работы с шаблонными классами, когда наследуемый интерфейс изначально неизвестен.
Но хочу вернуть обсуждение к моему изначальному вопросу - как сделать для программиста "быстрый старт" по цветовой схеме контролов?
И можно ли реализовать не функциональный (SetBgColor или SetProp(Enum_Color, ) и т.д.) а более универсальный класс аттрибутов.
Чтоб все контролы обращались к одному универсальному классу аттрибутов, но при этом кодер имел легкое понимание какой контрол какие цвета использует.
Но всё это моё рассуждение относительно моей схемы. Не исключаю, что она ещё очень сильно изменится, когда я начну переход на новый этап. Поэтому всё, что написал выше, может быть уже неактуально в рамках обсуждаемой здесь темы. )
В принципе согласен, будет понятно какие цвета он имеет и что можно менять.
такой вопрос тогда - Theme подразумевает избыточность неиспользуемых параметров?
Да, избыточно, для всех вариантов. Зато потом удобно создавать новую тему перекрасив и изменив значения в предыдущей. Как темы в Windows.
P.S.
И насчет массового изменения кодером каких-то значений отличающихся от используемых в текущей теме отношусь скептически. Напоминает проект на дельфи где первое что пытаются сделать это раскрасить в свои цвета интерфейс, который впоследствии не меняется при смене системной темы.
Да и зачем где-то размазывать стили оформления? Отнаследуй класс темы от одной из существующих и перекрой в ней только те значения, которые необходимо изменить.
есть такая технология CSS
1) известна и хорошо документирована
2) привычна и универсальна
3) в принципе теги==контролы, что делает её подходящей для нашей задачи
пробуйте, должно получится как задумано.
есть такая технология CSS
Тогда уж сразу смотрите на LESS / SCSS (SASS)
Тогда уж сразу смотрите на LESS / SCSS (SASS)
уф, лесс видимо хорошо, но его функциональных возможностей не надо. не интерпретатор делаем.
берём чисто сам принцип построения и переопределния стилей каскадом^выборочно^точечно - как они это делают.
И обязательно заложить возможность responsive дизайна (дизайн для разных разрешений). См. Media Queries в CSS
Причем некоторые части могут иметь фиксированные размеры, а другие тянутся на доступное им расстояние.
Уважаемые форумчане, я не имею желание никого демотивировать, но по моему мнению, обсуждаемая технология настолько сложна, что не может быть реализована совместными разрозненными усилиями. Эффективно объединить эти усилия мы не сможем, так как мы все отличаемся по уровням понимания, профессионализма и подходам... Нас также разделяют расстояния и даже страны.
Мой вывод: данная технология может быть реализована разработчиком-одиночкой, который долго и упорно над ней работал. Может, не один год. Но этот человек врядли станет делать эту технологию краудсорсовой, потому что пожертвовал слишком много сил, вложил душу, и просто изнурил себя этим трудом... Это его проект и он вправе не распостранять его свободно. (Может вначале, но не всегда).
Я думаю, что эта технология уже реализована на MQL.
P.S. Хотя, даже если так, - почему не попробывать ее реализовать еще раз? ))
Зачем это может пригодиться:
1. Интерфейс на битмапе быстрый. Настолько быстрый, что он практически неотличим от системного. Например, я реализовал полупрозрачные элементы с градиентами и даже при их движении они без видимых задержек плавно отрисовываются с учетом смешения цветов и расчета альфа канала на других объектах с полупрозрачными градиентами.
2. Интерфейс масштабируемый. Можно усложнять приложение и оно не будет замедляться по причине удаления и создания большого количества граф. объектов. Расходы на перерисовку минимальные, это всего лишь замена картинки, за тысячные доли секунды.
3. Можно создать готовые контролы и обеспечить возможность создать новые т.к. можно предусмотреть собственный пул событий, например:
OnMouseDown - нажали ЛКМ
OnMouseUp - отжали ЛКМ
OnMouseHoverOn - навели курсор мыши на объект
OnMouseHoverOut - отвели курсор мыши с объекта
OnMouseClick - нажали и отжали ЛКМ в границах объекта воздействия
OnMouseDblClick двойной клик ЛКМ в границах объекта воздействия
OnDragStart - событие возникающее 1 раз в начале движения с нажатой ЛКМ
OnDragMove - событие генерящееся в процессе движения С ЛКМ
OnDragEnd - событие генерящееся после движения с ЛКМ
OnPut - объект скинули на другой объект
OnGet - объекту кинули другой объект
OnFocus - объект получил фокус
OnBlur - объект потерял фокус
OnResize - у объекта изменился размер
OnParentResize - у родителя объекта изменился размер
OnKeyPress - произошло нажатие клавиши
OnChange - изменилось значение поля
и т.д.
Вы немного преувеличиваете в следующем:
Скорость рисования битмапа зависит от его размера. Если при перерисовке детали, Вы будете перерисовывать весь битмап представляющий окно, то реакция будет медленная (проверено). Очевидное решение - нужно чтобы перерисовывалась только область детали.
Однако, чтобы перерисовывать только часть рисунка битмап, представляющего окно, нужно чтобы цифровая маска этого битмапа сохранялась в памяти (в массиве). Далее, нужно ориентироваться в этой маске, и находить в ней нужную деталь. Однако, примите во внимание, что окон может быть много. Теперь оцените размер памяти, который нужен для хранения масок всех окон... Можно придумать систему приоритетов, которая будет выбирать какие окна запоминать, а какие "забывать", и когда. Однако, - дело не легкое.
Поймите, перерисовка - это переписываение значений в массиве, и если нужно переписать 1000000 значений (примерное количество пикселей в изображении окна и в битмапе), то это будут не " тысячные доли секунды", а секунды. Поэтому - рисовать окно полностью нужно только один раз, сохранять его в памяти и потом на событиях, - перерисовывать каждый объект в отдельности. Тогда скорость будет очень высокой.
По всей видимости Вы реализовали только отдельные объекты, но попробуйте создать окно и реализуйте там интерактивность своих элементов. Вы поймете о чем я говорю.
Что касается приведенных Вами событий, то их реализация в программе не связана с технологией рисования элементов управления и должна присутствовать в любом интерфейсе.
...
По всей видимости Вы реализовали только отдельные объекты, но попробуйте создать окно и реализуйте там интерактивность своих элементов. Вы поймете о чем я говорю.
...
Вы немного преувеличиваете в следующем:
Скорость рисования битмапа зависит от его размера. Если при перерисовке детали, Вы будете перерисовывать весь битмап представляющий окно, то реакция будет медленная (проверено). Очевидное решение - нужно чтобы перерисовывалась только область детали.
Однако, чтобы перерисовывать только часть рисунка битмап, представляющего окно, нужно чтобы цифровая маска этого битмапа сохранялась в памяти (в массиве). Далее, нужно ориентироваться в этой маске, и находить в ней нужную деталь. Однако, примите во внимание, что окон может быть много. Теперь оцените размер памяти, который нужен для хранения масок всех окон... Можно придумать систему приоритетов, которая будет выбирать какие окна запоминать, а какие "забывать", и когда. Однако, - дело не легкое.
Поймите, перерисовка - это переписываение значений в массиве, и если нужно переписать 1000000 значений (примерное количество пикселей в изображении окна и в битмапе), то это будут не " тысячные доли секунды", а секунды. Поэтому - рисовать окно полностью нужно только один раз, сохранять его в памяти и потом на событиях, - перерисовывать каждый объект в отдельности. Тогда скорость будет очень высокой.
По всей видимости Вы реализовали только отдельные объекты, но попробуйте создать окно и реализуйте там интерактивность своих элементов. Вы поймете о чем я говорю.
Что касается приведенных Вами событий, то их реализация в программе не связана с технологией рисования элементов управления и должна присутствовать в любом интерфейсе.
Хочу внести небольшое пояснение:
Сначала мы создаем цифровую маску окна со всеми ее элементами. Потом мы создаем битмап с помощью ResourceCreate(). У нас появляется наше окно на графике.
Далее, мы ведем мышкой по интерфейсу этого окна и ловим, допустим, событие наведения на элемент (_Object_Pointed).
Я опишу 2 подхода реализации интерактивности объекта, - один плохой, другой лучше:
1. Если цифровая маска нашего окна не была сохранена в массиве после первого создания, то чтобы изменить какую то деталь рисунка этого окна, нужно его полностью воссоздать. То есть произвести повторное цифровое построение. Само по себе это занимает время, потому что нужно инициализировать массив значениями цветов пикселей всех деталей окна, чтобы передать его в ResourceCreate(). Чем больше окно и чем больше в нем деталей, тем больше времени это займет (примерно от 250 милл.секунд до 2 секунды). И так, на каждом событии каждого элемента. Этот вариант слишком деффектный.
2. Если цифровая маска была сохранена в массиве, то нужно переинициализировать только те значения, которые имеют отношение к конкретной детали этого окна. Мы находим эту деталь в массиве и переписываем ее значения. Далее, - посылаем массив в ResourceCreate() и незамедлительно получаем результат.
Вот собственно и вся технология. Почти))