Обсуждение статьи "Пользовательские графические элементы управления. Часть 3. Формы"
Хороший и полезный труд, Дмитрий. Есть предложение для четвертой части: "Мастер форм" или "Визуальный редактор форм". Как смотришь на это?
Респект Дмитрий. Ты сделал капитальный труд.
Прими пожалуйста немного критики для следующей версии классов v4.
1. Абстракции в базовом проекте кассов мало. Получилось, что каждый элемент управления у тебя выступает как самостоятельная единица. В результате ты не можешь объединить их например в массив.
2. Каждый класс элемента имеет сейчас, по большому счету, свой уникальный набор функций. Это не очень хорошо. Должен быть один общий предок, функции которого просто переопределяются в потомках. Тем более что в нынешних классах очень много функций с одинаковым названием. что же мешает сделать общего предка?
3. Если появится базовый класс, то можно будет скрывать обработку событий внутри потомков, а не выносить обработку их всех наружу в форму. сделать так скажем каскад событий внутри объектов (на подобии CSS в вебе).
Но в общем все три части статьи достойны награды, особенно мне понравились "няшки" при нажатии кнопулек и их интерактивные отклики на нажатия в зависимости от состояния элемента.
PS.
А многоуровневое меню ты все таки добей, отдельной статьи на это не надо, слишком жирно для такой мелкой задачи статью новую писать. Пусть это будет просто апгрейдом в v4 версии.
Класс дерева CTreeCtrl можешь снять со статьи https://www.mql5.com/ru/articles/272 или предлагаемый в комплекте МТ CTreeNode.
- 2011.03.16
- o_O
- www.mql5.com
Хороший и полезный труд, Дмитрий. Есть предложение для четвертой части: "Мастер форм" или "Визуальный редактор форм". Как смотришь на это?
лично я смотрю положительно. Но надо ли оно? визуал упрошает лишь размещение объектов. Если же делать по уму, то надо привязывать и генерацию кода для созданных объектов, привязывание переменных, или классов к объекту. А главное обработку событий.
Но в данных неабстрактных классах этого не сделать. Очень уж они получились ручными. Надо во многих местах прописывать вновь созданные объекты и их обработку.
Для событий например нет такого разделения на системное и пользовательское - типа Draw (базовое системное) и OnDraw - добавка от юзера со своей отрисовкой.
В других структурах (например Joomla!) есть не только одна пользовательская функция OnDraw. А она делится на две - BeforDraw и AfterDraw. То есть программист может обрабатывать системное событие EVENT_DRAW - как до начала системной отрисовки так и после её окончания.
Респект Дмитрий. Ты сделал капитальный труд.
Прими пожалуйста немного критики для следующей версии классов v4.
1. Абстракции в базовом проекте кассов мало. Получилось, что каждый элемент управления у тебя выступает как самостоятельная единица. В результате ты не можешь объединить их например в массив.
2. Каждый класс элемента имеет сейчас, по большому счету, свой уникальный набор функций. Это не очень хорошо. Должен быть один общий предок, функции которого просто переопределяются в потомках. Тем более что в нынешних классах очень много функций с одинаковым названием. что же мешает сделать общего предка?
3. Если появится базовый класс, то можно будет скрывать обработку событий внутри потомков, а не выносить обработку их всех наружу в форму. сделать так скажем каскад событий внутри объектов (на подобии CSS в вебе).
Но в общем все три части статьи достойны награды, особенно мне понравились "няшки" при нажатии кнопулек и их интерактивные отклики на нажатия в зависимости от состояния элемента.
PS.
4. А многоуровневое меню ты все таки добей, отдельной статьи на это не надо, слишком жирно для такой мелкой задачи статью новую писать. Пусть это будет просто апгрейдом в v4 версии.
Класс дерева CTreeCtrl можешь снять со статьи https://www.mql5.com/ru/articles/272 или предлагаемый в комплекте МТ CTreeNode.
1. Однотипные элементы управления можно собрать в массив. Зачем разнотипные элементы управления собирать в один массив?
2. Если использовать базовый класс (один для всех элементов управления), это значит, что он должен иметь все методы которые только могут быть у любого из подклассов. С самостоятельными же классами, в выпадающем списке методов (при разработке), имеем только те методы, которые действительно существуют у класса. На мой взгляд очень существенный момент. Представляю, как кто-нибудь сидит и пытается вызвать метод SetWidth() для вертикального скроллбара.
Второй аргумент - все классы прокомментированы для doxygen, если будет базовый класс и подклассы, не будет столь явной структурированности в документации.
Стараюсь готовые решения делать такими, чтобы их можно было использовать с "закрытыми глазами". Для ускорения процесса создания нового элемента управления можно использовать шаблон со всеми обязательными методами.
3. Не совсем понял. Если элемент управления имеет в себе другой элемент управления, обработка его событий скрыта. В любом случае, для каждого элемента управления надо будет вызывать Event().
4. Не знаю, может быть... У меня есть свой класс, специально заточенный под создание меню, не надо вызывать всякие там AddNode(), вызывается AddItem() а уровень определяется количеством пробелов с которых начинается название пункта. Процесс создания дерева крайне нагляден. Пока работает с отображением в комментарии и управлением клавишами. Вообще можно сделать несколько древовидных меню: 1) как обычное главное меню с выпадающими вкладками, 2) отображаются пункты одной вкладки и путь наверх, 3) с отображением дерева (как проводник виндос).
1. лично я смотрю положительно. Но надо ли оно? визуал упрошает лишь размещение объектов. Если же делать по уму, то надо привязывать и генерацию кода для созданных объектов, привязывание переменных, или классов к объекту. А главное обработку событий.
2. Но в данных неабстрактных классах этого не сделать. Очень уж они получились ручными. Надо во многих местах прописывать вновь созданные объекты и их обработку.
Для событий например нет такого разделения на системное и пользовательское - типа Draw (базовое системное) и OnDraw - добавка от юзера со своей отрисовкой.
В других структурах (например Joomla!) есть не только одна пользовательская функция OnDraw. А она делится на две - BeforDraw и AfterDraw. То есть программист может обрабатывать системное событие EVENT_DRAW - как до начала системной отрисовки так и после её окончания.
1. Как раз можно будет автоматически сгенерировать код обработки событий элементов управления и получить функции событий для всех элементов управления, типа HScrollBar1_OnChange()...
2. Еще нет событий, например, при программной установке значений, события генерируюся только при вводе значений пользователем. Это достаточный минимум, ничего лишнего. Иначе, кто-нибудь, самостоятельно изучающий программирование, засыпится событиями.
Хороший и полезный труд, Дмитрий. Есть предложение для четвертой части: "Мастер форм" или "Визуальный редактор форм". Как смотришь на это?
... Есть предложение для четвертой части: "Мастер форм" или "Визуальный редактор форм". Как смотришь на это?
1. Однотипные элементы управления можно собрать в массив. Зачем разнотипные элементы управления собирать в один массив?
чтобы увести все в один цикл и избавится от конкретных типов в обслуживании событий.
2. Если использовать базовый класс (один для всех элементов управления), это значит, что он должен иметь все методы которые только могут быть у любого из подклассов. С самостоятельными же классами, в выпадающем списке методов (при разработке), имеем только те методы, которые действительно существуют у класса. На мой взгляд очень существенный момент. Представляю, как кто-нибудь сидит и пытается вызвать метод SetWidth() для вертикального скроллбара.
в том и дело что базовый класс - он не имеет реализации функций конкретных действий. Все функции в базовом классе пустышки-заглушки с минимальным общим функционалом. Даже если кто-то по незнанию вызовет несвойственный функционал для элемента, то абсолютно ничего плохого не произойддет. в этом ведь и есть сила ООП. Полиморфизм однако.
Второй аргумент - все классы прокомментированы для doxygen, если будет базовый класс и подклассы, не будет столь явной структурированности в документации.
будет. только она будет другой... :)
- 2010.03.25
- MetaQuotes Software Corp.
- www.mql5.com
1. чтобы увести все в один цикл и избавится от конкретных типов в обслуживании событий.
2. в том и дело что базовый класс - он не имеет реализации функций конкретных действий. Все функции в базовом классе пустышки-заглушки с минимальным общим функционалом. Даже если кто-то по незнанию вызовет несвойственный функционал для элемента, то абсолютно ничего плохого не произойддет. в этом ведь и есть сила ООП. Полиморфизм однако.
3. будет. только она будет другой... :)
1. И это все? Ради этого пудрить себе мозг пунктом 2 - свалкой методов?
Альтернативы:
1) Необходимость вручную добавить вызов Event() для каждого класса (что заключается в копировании мышкой одной строки и изменении нескольких буквочек левее точки) и при этом, в списке методов каждого класса имеем только рабочие методы соответствующие этому классу, нажал точку, вывалился список и все понятно.
2) Автоматическая обработка Event() всех классов, притом, что одну функцию все равно надо будет вызывать из OnChartEvent(), а с другой стороны: свалка методов в списке. Еще, надо будет уничтожать указатели в деините.
Посмотрите немного глубже и дальше, зачем вообще все Event() обрабатывать в одном цикле, для каждого элемента управления по его Event() должны выполняться свои действия, элементы управления предназначены не только для ввода значения и не только для того, что на экране все двигалось и мерцало, а еще для того (в главной степени), чтобы введенные значения использовать в программе.
3. Про половину методов одного элемента управления придется читать в одном месте документации, про вторую половину - в другом.
1. И это все? Ради этого пудрить себе мозг пунктом 2 - свалкой методов?
Альтернативы:
1) Необходимость вручную добавить вызов Event() для каждого класса (что заключается в копировании мышкой одной строки и изменении нескольких буквочек левее точки) и при этом, в списке методов каждого класса имеем только рабочие методы соответствующие этому классу, нажал точку, вывалился список и все понятно.
2) Автоматическая обработка Event() всех классов, притом, что одну функцию все равно надо будет вызывать из OnChartEvent(), а с другой стороны: свалка методов в списке. Еще, надо будет уничтожать указатели в деините.
Посмотрите немного глубже и дальше, зачем вообще все Event() обрабатывать в одном цикле, для каждого элемента управления по его Event() должны выполняться свои действия, элементы управления предназначены не только для ввода значения и не только для того, что на экране все двигалось и мерцало, а еще для того (в главной степени), чтобы введенные значения использовать в программе.
3. Про половину методов одного элемента управления придется читать в одном месте документации, про вторую половину - в другом.
Всё правильно сделал.
С учётом возможностей МЕ вполне удобно, японский минимализм в эпоху тотального кича, всё есть, ничего лишнего.
Кто желает перебирать объекты циклом, вполне может реализовать постфиксную оболочку где прописать всё что душеньке пожелается.
Опубликована статья Пользовательские графические элементы управления. Часть 3. Формы:
Этой последняя из трех статей, посвященных графическим элементам управления. В ней рассматривается создание главного элемента графического интерфейса, формы, и ее совместное использование с другими элементами управления. Кроме классов формы библиотека элементов управления дополнена классами CFrame, CButton, CLabel.
Автор: Дмитрий