Скачать MetaTrader 5

Обсуждение статьи "Пользовательские графические элементы управления. Часть 3. Формы"

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
MetaQuotes Software Corp.
Модератор
185916
MetaQuotes Software Corp.  

Опубликована статья Пользовательские графические элементы управления. Часть 3. Формы:

Этой последняя из трех статей, посвященных графическим элементам управления. В ней рассматривается создание главного элемента графического интерфейса, формы, и ее совместное использование с другими элементами управления. Кроме классов формы библиотека элементов управления дополнена классами CFrame, CButton, CLabel.

Рис. 5. Взаимодействие функций эксперта с методами классов формы

Автор: Дмитрий

Konstantin Gruzdev
14712
Konstantin Gruzdev  

Хороший и полезный труд, Дмитрий. Есть предложение для четвертой части: "Мастер форм" или "Визуальный редактор форм". Как смотришь на это?

o_o
Модератор
24105
o_o  

Респект Дмитрий. Ты сделал капитальный труд.

Прими пожалуйста немного критики для следующей версии классов v4.

1. Абстракции в базовом проекте кассов мало. Получилось, что каждый элемент управления у тебя выступает как самостоятельная единица. В результате ты не можешь объединить их например в массив.

2. Каждый класс элемента имеет сейчас, по большому счету, свой уникальный набор функций. Это не очень хорошо. Должен быть один общий предок, функции которого просто переопределяются в потомках. Тем более что в нынешних классах очень много функций с одинаковым названием. что же мешает сделать общего предка?

3. Если появится базовый класс, то можно будет скрывать обработку событий внутри потомков, а не выносить обработку их всех наружу в форму. сделать так скажем каскад событий внутри объектов (на подобии CSS в вебе).


Но в общем все три части статьи достойны награды, особенно мне понравились "няшки" при нажатии кнопулек и их интерактивные отклики на нажатия в зависимости от состояния элемента.

PS.
А многоуровневое меню ты все таки добей, отдельной статьи на это не надо, слишком жирно для такой мелкой задачи статью новую писать. Пусть это будет просто апгрейдом в v4 версии.
Класс дерева CTreeCtrl можешь снять со статьи https://www.mql5.com/ru/articles/272 или предлагаемый в комплекте МТ CTreeNode.

Трассировка, отладка и структурный анализ кода
Трассировка, отладка и структурный анализ кода
  • 2011.03.16
  • o_O
  • www.mql5.com
Весь комплекс задач создания структуры работающего кода и его трассировки можно решить без особых сложностей. Эта возможность появилась в MetaTrader 5 благодаря новому свойству языка MQL5 - автоматическое создание переменных сложного типа данных (структуры и классы) и их уничтожение при выходе из локальной области видимости. В статье описана методика и предоставлен готовый инструмент.
o_o
Модератор
24105
o_o  
Lizar:

Хороший и полезный труд, Дмитрий. Есть предложение для четвертой части: "Мастер форм" или "Визуальный редактор форм". Как смотришь на это?

лично я смотрю положительно. Но надо ли оно? визуал упрошает лишь размещение объектов. Если же делать по уму, то надо привязывать и генерацию кода для созданных объектов, привязывание переменных, или классов к объекту. А главное обработку событий.

Но в данных неабстрактных классах этого не сделать. Очень уж они получились ручными. Надо во многих местах прописывать вновь созданные объекты и их обработку.
Для событий например нет такого разделения на системное и пользовательское - типа Draw (базовое системное) и OnDraw - добавка от юзера со своей отрисовкой.

В других структурах (например Joomla!) есть не только одна пользовательская функция OnDraw. А она делится на две - BeforDraw и AfterDraw. То есть программист может обрабатывать системное событие EVENT_DRAW - как до начала системной отрисовки так и после её окончания.


Dmitry Fedoseev
45878
Dmitry Fedoseev  
sergeev:

Респект Дмитрий. Ты сделал капитальный труд.

Прими пожалуйста немного критики для следующей версии классов 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) с отображением дерева (как проводник виндос). 

 

Dmitry Fedoseev
45878
Dmitry Fedoseev  
sergeev:

1. лично я смотрю положительно. Но надо ли оно? визуал упрошает лишь размещение объектов. Если же делать по уму, то надо привязывать и генерацию кода для созданных объектов, привязывание переменных, или классов к объекту. А главное обработку событий.

2. Но в данных неабстрактных классах этого не сделать. Очень уж они получились ручными. Надо во многих местах прописывать вновь созданные объекты и их обработку. 
Для событий например нет такого разделения на системное и пользовательское - типа Draw (базовое системное) и OnDraw - добавка от юзера со своей отрисовкой.

В других структурах (например Joomla!) есть не только одна пользовательская функция OnDraw. А она делится на две - BeforDraw и AfterDraw. То есть программист может обрабатывать системное событие EVENT_DRAW - как до начала системной отрисовки так и после её окончания.


1. Как раз можно будет автоматически сгенерировать код обработки событий элементов управления и получить функции событий для всех элементов управления, типа HScrollBar1_OnChange()...

2. Еще нет событий, например, при программной установке значений, события генерируюся только при вводе значений пользователем. Это достаточный минимум, ничего лишнего. Иначе, кто-нибудь, самостоятельно изучающий программирование, засыпится событиями.

Dmitry Fedoseev
45878
Dmitry Fedoseev  
Lizar:

Хороший и полезный труд, Дмитрий. Есть предложение для четвертой части: "Мастер форм" или "Визуальный редактор форм". Как смотришь на это?

Положительно смотрю. Уже придумал, как это сделать малым потом и без тяжелой артиллерии. Только в ближайшее время я в отпуске, после отпуска можно будет.  Если Rosh не против.
Sergey Pavlov
10171
Sergey Pavlov  
Lizar:

... Есть предложение для четвертой части: "Мастер форм" или "Визуальный редактор форм". Как смотришь на это?

"Всё уже украдено до нас" (Операция Ы)
o_o
Модератор
24105
o_o  
Integer:

1. Однотипные элементы управления можно собрать в массив. Зачем разнотипные элементы управления собирать в один массив?

чтобы увести все в один цикл и избавится от конкретных типов в обслуживании событий.

2. Если использовать базовый класс (один для всех элементов управления), это значит, что он должен иметь все методы которые только могут быть у любого из подклассов. С самостоятельными же классами, в выпадающем списке методов (при разработке), имеем только те методы, которые действительно существуют у класса. На мой взгляд очень существенный момент. Представляю, как кто-нибудь сидит и пытается вызвать метод SetWidth() для вертикального скроллбара.

в том и дело что базовый класс - он не имеет реализации функций конкретных действий.  Все функции в базовом классе пустышки-заглушки с минимальным общим функционалом. Даже если кто-то по незнанию вызовет несвойственный функционал для элемента, то абсолютно ничего плохого не произойддет. в этом ведь и есть сила ООП. Полиморфизм однако.

Второй аргумент - все классы прокомментированы для doxygen, если будет базовый класс и подклассы, не будет столь явной структурированности в документации.

будет. только она будет другой... :)

Когда нужно использовать указатели в MQL5
Когда нужно использовать указатели в MQL5
  • 2010.03.25
  • MetaQuotes Software Corp.
  • www.mql5.com
Все объекты в MQL5 по умолчанию передаются по ссылке, но есть возможность использовать и указатели объектов. При этом есть опасность получить в качестве параметра функции указатель неинициализированного объекта. В этом случае работа программы будет завершена критически с последующей выгрузкой. Автоматически создаваемые объекты как правило такой ошибки не вызывают, и в этом отношении они достаточно безопасны. В этой статье мы попробуем разобраться в чем разница между ссылкой и указателей, когда оправдано использование указателей и как написать безопасный код с использованием указателей.
Dmitry Fedoseev
45878
Dmitry Fedoseev  
sergeev:

1. чтобы увести все в один цикл и избавится от конкретных типов в обслуживании событий.

2. в том и дело что базовый класс - он не имеет реализации функций конкретных действий.  Все функции в базовом классе пустышки-заглушки с минимальным общим функционалом. Даже если кто-то по незнанию вызовет несвойственный функционал для элемента, то абсолютно ничего плохого не произойддет. в этом ведь и есть сила ООП. Полиморфизм однако.

3. будет. только она будет другой... :)

1. И это все? Ради этого пудрить себе мозг пунктом 2 - свалкой методов?

Альтернативы:

1) Необходимость вручную добавить вызов Event() для каждого класса (что заключается в копировании мышкой одной строки и изменении нескольких буквочек левее точки) и при этом, в списке методов каждого класса имеем только рабочие методы соответствующие этому классу, нажал точку, вывалился список и все понятно.

2) Автоматическая обработка Event() всех классов, притом, что одну функцию все равно надо будет вызывать из OnChartEvent(), а с другой стороны: свалка методов в списке. Еще, надо будет уничтожать указатели в деините. 

Посмотрите немного глубже и дальше, зачем вообще все Event() обрабатывать в одном цикле, для каждого элемента управления по его Event() должны выполняться свои действия, элементы управления предназначены не только для ввода значения и не только для того, что на экране все двигалось и мерцало, а еще для того (в главной степени), чтобы введенные значения использовать в программе.

3. Про половину методов одного элемента управления придется читать в одном месте документации, про вторую половину - в другом.

 


Nikolay Demko
12568
Nikolay Demko  
Integer:

1. И это все? Ради этого пудрить себе мозг пунктом 2 - свалкой методов?

Альтернативы:

1) Необходимость вручную добавить вызов Event() для каждого класса (что заключается в копировании мышкой одной строки и изменении нескольких буквочек левее точки) и при этом, в списке методов каждого класса имеем только рабочие методы соответствующие этому классу, нажал точку, вывалился список и все понятно.

2) Автоматическая обработка Event() всех классов, притом, что одну функцию все равно надо будет вызывать из OnChartEvent(), а с другой стороны: свалка методов в списке. Еще, надо будет уничтожать указатели в деините. 

Посмотрите немного глубже и дальше, зачем вообще все Event() обрабатывать в одном цикле, для каждого элемента управления по его Event() должны выполняться свои действия, элементы управления предназначены не только для ввода значения и не только для того, что на экране все двигалось и мерцало, а еще для того (в главной степени), чтобы введенные значения использовать в программе.

3. Про половину методов одного элемента управления придется читать в одном месте документации, про вторую половину - в другом.


Всё правильно сделал.

С учётом возможностей МЕ вполне удобно, японский минимализм в эпоху тотального кича, всё есть, ничего лишнего.

Кто желает перебирать объекты циклом, вполне может реализовать постфиксную оболочку где прописать всё что душеньке пожелается.

123
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий