Делаем краудсорсовый проект по Canvas - страница 36
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Любой элемент диалога (форма, элемент управления (кнопка, список, картинка)) обладает какими-либо свойствами. Процедурное программирование не определяет понятия "свойство" или "поле". При процедурном программировании мы имеем функции и переменные (глобальные или локальные). Но переменные являются общими для, значит не могут использоваться для описания свойств каждого отдельного элемента управления. Тогда какой выход? Да простой - структуры!
Да, структура может иметь описание необходимых свойств элемента управления, а так же массив вложенных (до бесконечности) элементов управления.
Все это дело сохраняется в массиве диалоговых окон.
Можно сделать более универсально: структура описания элемента управления состоит из двух массивов: массив свойств и массив подчиненных элементов. Массив свойств - это массив структур пары "Свойство-значение". При таком подходе каждый новый элемент управления может обладать любым произвольным набором свойств. Но это не удобно для обработки. Более логичным будет указание в структуре конкретных свойств элемента управления: габариты, расположение, цвет, рамка и прочее, и прочее - все что необходимо любому элементу управления.
Ну и еще в структуре будет массив пикселей данного элемента.
При получении события мыши в цикле обходятся все массивы на проверку попадания курсора в конкретный элемент управления. Проверка проводится от последнего к первому.
Как только выявили в какой элемент управления попал курсор тогда данный элемент массива отправляет в функцию перерисовки, а затем обновляем массив ресурса и обновляем картинку на графике.
Я не знаю, что он выкладывал и чем занимался в вопросах GUI, но в моих ветках он не сделал ни одного технического предложения, ни одного решения и не вел никаких обсуждений по теме. Только пустой троллинг, указание на сторонние решения и призывы не изобретать велосипед.
Вернемся к теме.
На сколько я знаком со стандартной библиотекой (очень мало на самом деле), там элементы и окна состоят из МТ-объектов. То есть, в нашем контексте, - они не нарисованы на канвасе. Конечно, они нарисованы, но не на нашем канвасе, что не дает нам возможность управлять цветами пикселей, создавать градиенты поверхностей и многое другое.
В теории, можно взять структуру библиотеки, скопировать и сделать аналог на канвасе. В теории...
Проблема в том, что сам ССanvas - не удобен для создания GUI на нем. Почему? Потому что там система работы с канвасом приспособлена в основном для графических примитивов. То есть, по сути, ничего кроме примитивов этот класс не предоставляет. Архетиктуру ГУИ нужно строить самому. А в этом случае, класс необязателен. Удобнее обойтись своими решениями. Ведь нарисовать прямоугольную метку можно и без этого класса. Как и создать или загрузить канвас. Это очень просто. Поэтому, я предпочел свое решение.
Но, кому то без CCanvas никак. Поэтому, не настаиваю.
Проблемой CCanvas является то, что его GUI строго завязан на окно графика.
То есть полноценное окно в виде модуля интерфейса терминала, не сделать.
А было бы очень круто, писать свои модули интерфейса.
немного конечно не так :-)
я выкладывал интерфейс к DLL Tcl (который Tool Common Language), у которого графика Tk , которые совместно используются как GUI в Python/Ruby/etc
не было целью получить GUI, это как-бы приятный побочный результат :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
на мой взгляд удобно, а главное кратко :-)
никого не агитирую - я tcl/tk знаю, использую, наработками поделился (см. sourceforge atcl)
Да, Макс, именно про TCL и твой прототип, который мы тогда обсуждали, я и говорю. Там было ограничение в том, что у пользователя на компе должна быть установлена соответствующая библиотека. Вроде как не сложно, но все же это определенное ограничение.
Оставим это в прошлом. Макс, включайся в рассуждения. Роман, тоже подключайся ))).
Исходя из вышесказанного можно понять что элемент структуры является конкретным элементом управления диалога, он содержит свои собственные свойства и может содержать вложенные элементы управления. Набор свойств такого универсального элемента управления ограничивается только фантазией разработчика.
Конечно можно и не подниматься до структуры, а описывать свойства элементов управления в многомерном массиве, но это не рентабильно изначально так как нужно четко помнить в каком индексе хранится какое-то свойство. Да и массив не может содержать разнородные типы данных. Получается что описывать элемент управления при процедурном программировании возможно только через структуры. То есть элемент структуры - это конкретный элемент управления, то есть конкретный объект диалога со своими свойствами.
Проблемой CCanvas является то, что его GUI строго завязан на окно графика.
То есть полноценное окно в виде модуля интерфейса терминала, не сделать.
А было бы очень круто, писать свои модули интерфейса.
потом будет обратная фигнь - привязать интерфейс в график. Например сделать кнопку которая строго привязана к метке времени и цене.
вот отдельный GUI пишется влёт - со всеми таблицами, вкладками, менюшками и свистюшками. На C# или даже бейсике. А внутрь чарта - это существенная проблема для внешних приложений.
Любой элемент диалога (форма, элемент управления (кнопка, список, картинка)) обладает какими-либо свойствами. Процедурное программирование не определяет понятия "свойство" или "поле". При процедурном программировании мы имеем функции и переменные (глобальные или локальные). Но переменные являются общими для, значит не могут использоваться для описания свойств каждого отдельного элемента управления. Тогда какой выход? Да простой - структуры!
Да, структура может иметь описание необходимых свойств элемента управления, а так же массив вложенных (до бесконечности) элементов управления.
Все это дело сохраняется в массиве диалоговых окон.
Можно сделать более универсально: структура описания элемента управления состоит из двух массивов: массив свойств и массив подчиненных элементов. Массив свойств - это массив структур пары "Свойство-значение". При таком подходе каждый новый элемент управления может обладать любым произвольным набором свойств. Но это не удобно для обработки. Более логичным будет указание в структуре конкретных свойств элемента управления: габариты, расположение, цвет, рамка и прочее, и прочее - все что необходимо любому элементу управления.
Ну и еще в структуре будет массив пикселей данного элемента.
При получении события мыши в цикле обходятся все массивы на проверку попадания курсора в конкретный элемент управления. Проверка проводится от последнего к первому.
Как только выявили в какой элемент управления попал курсор тогда данный элемент массива отправляет в функцию перерисовки, а затем обновляем массив ресурса и обновляем картинку на графике.
1. Допустим, вы спроектировали простейшую структуру базовых элементов управления - окно, кнопка, чекбокс. Каждый состоит из набора составных частей - объектов. Чекбокс - основание, текст, иконка. Кнопка - основание, текст, иконка и так далее. Каждый объект каждого элемента должен обладать набором своих свойств. Можете их прописать в структуре или классе, но на мой взгляд - это неудобно. Почему? - потому что расположив их в окне, вам нужно их находить на канвасе курсором. Когда перемещаете курсор, они должны попадать в фокус. Для этого, их текущие координаты должны быть в массиве. И удобнее, если все их свойства (включая текущие координаты) в одном массиве. Так вы можете сразу получать доступ к любому свойству любого элемента на канвасе, который попадает в фокус курсора. Также, по массиву элементов проще делать цикл.
То есть, проще обходить ОДИН массив в цикле поиска элемента, на который попал курсор. И еще удобнее, если этот массив глобальный. Тогда в любой функции можно из него взять нужную информацию и в любой функции изменить значения нужных свойств, нужных элементов.
Это самый краткий и эффективный доступ к элементам и самая быстрая их обработка. Это мое "ядро".
2. Однако, зная прихоти профессионалов стремится к максимальному подражанию стандартному ООП я не предлагаю эту технологию.
3. Массив пикселей не нужно нигде хранить. Он строиться в момент необходимости по параметрам элементов в массиве. Например: нужно перерисовать окно. Вызываем функцию перерисовки. Функция обращается к массиву элементов, видит все свойства, объявляет массив пикселей, рассчитывает его размер, последовательно в цикле по элементам рисует их объекты, вызывает ResourceCreate(). Все.
4. Элемент попавший под курсор отправляется на перерисовку в ту же функцию. Она получает уведомление (флаг перерисовки элемента) и его номер в массиве элементов. Далее, функция вызывает через ResourceReadImage() нужный ресурс, запихивает его в массив пикселей, и дальше, внутри массива пикселей находит область нужного элемента и перерисовывает все его объекты. сохраняет через ResourceCreate(). Все.
1. Допустим, вы спроектировали простейшую структуру базовых элементов управления - окно, кнопка, чекбокс. Каждый состоит из набора составных частей - объектов. Чекбокс - основание, текст, иконка. Кнопка - основание, текст, иконка и так далее. Каждый объект каждого элемента должен обладать набором своих свойств. Можете их прописать в структуре или классе, но на мой взгляд - это неудобно. Почему? - потому что расположив их в окне, вам нужно их находить на канвасе курсором. Когда перемещаете курсор, они должны попадать в фокус. Для этого, их текущие координаты должны быть в массиве. И удобнее, если все их свойства (включая текущие координаты) в одном массиве. Так вы можете сразу получать доступ к любому свойству любого элемента на канвасе, который попадает в фокус курсора. Также, по массиву элементов проще делать цикл.
То есть, проще обходить ОДИН массив в цикле поиска элемента, на который попал курсор. И еще удобнее, если этот массив глобальный. Тогда в любой функции можно из него взять нужную информацию и в любой функции изменить значения нужных свойств, нужных элементов.
Это самый краткий и эффективный доступ к элементам и самая быстрая их обработка. Это мое "ядро".
2. Однако, зная прихоти профессионалов стремится к максимальному подражанию стандартному ООП я не предлагаю эту технологию.
3. Массив пикселей не нужно нигде хранить. Он строиться в момент необходимости по параметрам элементов в массиве. Например: нужно перерисовать окно. Вызываем функцию перерисовки. Функция обращается к массиву элементов, видит все свойства, объявляет массив пикселей, рассчитывает его размер, последовательно в цикле по элементам рисует их объекты, вызывает ResourceCreate(). Все.
4. Элемент попавший под курсор отправляется на перерисовку в ту же функцию. Она получает уведомление (флаг перерисовки элемента) и его номер в массиве элементов. Далее, функция вызывает через ResourceReadImage() нужный ресурс, запихивает его в массив пикселей, и дальше, внутри массива пикселей находит область нужного элемента и перерисовывает все его объекты. сохраняет через ResourceCreate(). Все.
Вообще-то это должно происходить независимо от технологии построения. Только воспринимать это можно по разному. В Вашем случае вы проходите в цикле массив и определяете в какой элемент управления попал в данный момент курсор. Если исходить из вышесказанного то определив индекс Вы тут же видите и свойства найденного элемента. Но как можно хранить в одном большом массиве разные типы данных?
Вообще-то это должно происходить независимо от технологии построения. Только воспринимать это можно по разному. В Вашем случае вы проходите в цикле массив и определяете в какой элемент управления попал в данный момент курсор. Если исходить из вышесказанного то определив индекс Вы тут же видите и свойства найденного элемента. Но как можно хранить в одном большом массива разные типы данных?
В принципе, можно обобщить типы. Я пришел к выводу, что ничего страшного не случится, если подавляющее большинство свойств объектов будут иметь тип int. Все остальные (double практически отсутствует в свойствах граф.объектов) сокращенные типы я отмел ради упрощения. "Перерасход" памяти настолько ничтожный, что думать о нем нет смысла. Конечно, ради пущего профессионализма на такое кощунство пойтить никак нельзя))) Но, сейчас 21-й век и костер мне не грозит.))
Имена объектов я сделал номерами, и всунул в общий ряд свойств объектов.
Единственное, где мне понадобился иной тип данных - это параметры элементов управления. Там я создал второе ядро, которое хранит свойства параметров, а сами значения в типе string, которое я легко привожу к чему угодно (точнее, к тому, что прописано в свойствах параметра).
ЗЫ. Под "параметром элемента управления" подразумевается УПРАВЛЯЕМЫЙ ЭЛЕМЕНТОМ ПАРАМЕТР.1. Допустим, вы спроектировали простейшую структуру базовых элементов управления - окно, кнопка, чекбокс. Каждый состоит из набора составных частей - объектов. Чекбокс - основание, текст, иконка. Кнопка - основание, текст, иконка и так далее. Каждый объект каждого элемента должен обладать набором своих свойств. Можете их прописать в структуре или классе, но на мой взгляд - это неудобно. Почему? - потому что расположив их в окне, вам нужно их находить на канвасе курсором. Когда перемещаете курсор, они должны попадать в фокус. Для этого, их текущие координаты должны быть в массиве. И удобнее, если все их свойства (включая текущие координаты) в одном массиве. Так вы можете сразу получать доступ к любому свойству любого элемента на канвасе, который попадает в фокус курсора. Также, по массиву элементов проще делать цикл.
То есть, проще обходить ОДИН массив в цикле поиска элемента, на который попал курсор. И еще удобнее, если этот массив глобальный. Тогда в любой функции можно из него взять нужную информацию и в любой функции изменить значения нужных свойств, нужных элементов.
Это самый краткий и эффективный доступ к элементам и самая быстрая их обработка. Это мое "ядро".
2. Однако, зная прихоти профессионалов стремится к максимальному подражанию стандартному ООП я не предлагаю эту технологию.
3. Массив пикселей не нужно нигде хранить. Он строиться в момент необходимости по параметрам элементов в массиве. Например: нужно перерисовать окно. Вызываем функцию перерисовки. Функция обращается к массиву элементов, видит все свойства, объявляет массив пикселей, рассчитывает его размер, последовательно в цикле по элементам рисует их объекты, вызывает ResourceCreate(). Все.
4. Элемент попавший под курсор отправляется на перерисовку в ту же функцию. Она получает уведомление (флаг перерисовки элемента) и его номер в массиве элементов. Далее, функция вызывает через ResourceReadImage() нужный ресурс, запихивает его в массив пикселей, и дальше, внутри массива пикселей находит область нужного элемента и перерисовывает все его объекты. Все.
ухх уж этот вечный негатив к ооп, прям через строчку
А вы не задумывались как он появился. Дело в том что много кто пишет в процедурном стиле и не зная об ООП сталкиваются с желанием сгруппировать функции, потом это желание перерастает в желание объединить эти функциюв одну область памяти и ссылаться на неё, т.е. физически ссылка на участок с функциями которая храниться в переменной. Потом появляеться желание внести изменения в нашу выбранную кучку функций но при этом не дублируя код (получаем наследования). Так человек изначально знакомый только с процедурным стилем через какое то время задает вопрос - почему в мкл столько ограничений (отсылка на множественное наследования).
Вобще, считается, что человека проще сразу обучать ООП, так как если он ознакомится с процедурным стилем, потом переобучение будет проходить очень тяжело (у основной массы людей), но есть и другие , т.к. изначально был только процедурный стиль... описал выше.
ЗЫ В ООП вобще есть разновидность, типо знаком с ООП на уровне процедурного кода, и реально использую ООП по полной.
Класс это ссылка на память (таблицу) функций, которые можно переписывать и дописывать сохраняя основной масив + ссылка на переменые. и уже забыл чего еще.... (вроде 32 байта должен весить)
С поиском вечная задача, я тут недавно сравнивал встроенную функцию сортировки с Ред сортировкой (одной из шаблонных), проигрыш в скорости в 3-6 раз в определенных условиях (встроенная проиграла =)
НА GUI думаю есть стандартные методы.
,
ухх уж этот вечный негатив к ооп, прям через строчку
А вы не задумывались как он появился. Дело в том что много кто пишет в процедурном стиле и не зная об ООП сталкиваются с желанием сгруппировать функции, потом это желание перерастает в желание объединить эти функциюв одну область памяти и ссылаться на неё, т.е. физически ссылка на участок с функциями которая храниться в переменной. Потом появляеться желание внести изменения в нашу выбранную кучку функций но при этом не дублируя код (получаем наследования). Так человек изначально знакомый только с процедурным стилем через какое то время задает вопрос - почему в мкл столько ограничений (отсылка на множественное наследования).
Вобще, считается, что человека проще сразу обучать ООП, так как если он ознакомится с процедурным стилем, потом переобучение будет проходить очень тяжело (у основной массы людей), но есть и другие , т.к. изначально был только процедурный стиль... описал выше.
ЗЫ В ООП вобще есть разновидность, типо знаком с ООП на уровне процедурного кода, и реально использую ООП по полной.
Класс это ссылка на память (таблицу) функций, которые можно переписывать и дописывать сохраняя основной масив + ссылка на переменые. и уже забыл чего еще.... (вроде 32 байта должен весить)
С поиском вечная задача, я тут недавно сравнивал встроенную функцию сортировки с Ред сортировкой (одной из шаблонных), проигрыш в скорости в 3-6 раз в определенных условиях (встроенная проиграла =)
НА GUI думаю есть стандартные методы.
,
Никакого негатива к концепции ООП у меня нет. Я сам ее приверженец. У меня негатив к стандартам. Точнее, к бездумному следованию им.)
В остальном, я за ООП. Но, за упрощенный.