Скачать MetaTrader 5
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Зарабатывай на сервисах MQL5. Это просто!
MetaQuotes Software Corp.
Модератор
180334
MetaQuotes Software Corp. 2011.08.21 19:35 

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

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

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

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

Konstantin Gruzdev
13906
Konstantin Gruzdev 2011.08.21 20:30  

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

o_O
Модератор
23616
o_O 2011.08.22 00:53  

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

Прими пожалуйста немного критики для следующей версии классов 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
Модератор
23616
o_O 2011.08.22 01:10  
Lizar:

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

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

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

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


Dmitry Fedoseev
42657
Dmitry Fedoseev 2011.08.22 02:24  
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
42657
Dmitry Fedoseev 2011.08.22 02:35  
sergeev:

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

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

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


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

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

Dmitry Fedoseev
42657
Dmitry Fedoseev 2011.08.22 02:38  
Lizar:

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

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

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

"Всё уже украдено до нас" (Операция Ы)
o_O
Модератор
23616
o_O 2011.08.22 12:31  
Integer:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 


Nikolay Demko
12452
Nikolay Demko 2011.08.23 00:47  
Integer:

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

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

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

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

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

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


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

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

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

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