Обсуждение статьи "Пользовательские графические элементы управления. Часть 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. Про половину методов одного элемента управления придется читать в одном месте документации, про вторую половину - в другом.
Всё правильно сделал.
С учётом возможностей МЕ вполне удобно, японский минимализм в эпоху тотального кича, всё есть, ничего лишнего.
Кто желает перебирать объекты циклом, вполне может реализовать постфиксную оболочку где прописать всё что душеньке пожелается.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Пользовательские графические элементы управления. Часть 3. Формы:
Этой последняя из трех статей, посвященных графическим элементам управления. В ней рассматривается создание главного элемента графического интерфейса, формы, и ее совместное использование с другими элементами управления. Кроме классов формы библиотека элементов управления дополнена классами CFrame, CButton, CLabel.
Автор: Дмитрий