Создание формы настроек приложения с деревом категорий

Всем привет!
Нужно сделать форму на подобие этой


и тут возникла пара вопросов что за элемент с левой стороны? похоже на treeView, или это он и есть только вид другой

и второе, при выборе позиции в левой части что то должно появиться в правой, понятно что можно туда добавить динамически созданные контролы, а можно ли как то использовать нарисованные?

Спасибо!

0

Сообщение от Slavok47 что за элемент с левой стороны?

Это обычный виндовый TreeView (класс контрола SysTreeView32).

Сообщение от Slavok47 при выборе позиции в левой части что то должно появиться в правой, понятно что можно туда добавить динамически созданные контролы, а можно ли как то использовать нарисованные?

Вы можете создать несколько UserControl'ов в дизайнере и показывать/скрывать их в зависимости от выбора в TreeView.

1

Сообщение от Someone007 Вы можете создать несколько UserControl'ов в дизайнере и показывать/скрывать их в зависимости от выбора в TreeView.

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

0

А Вы сделайте TabControl с невидимыми Tab-ами

0

Defazze, это говнокод. Слушайте Someone007,
UserControl отдельные, а не на форме. Создавать и показывать их динамически, в зависимости от выбора в дереве.

1

Сообщение от Rius Defazze, это говнокод.

С чего вдруг? Обыкновенное решение.

2

Defazze, обыкновенное говнокодерское решение. Потому что при большом количестве контролов форма создаётся неадекватно долго. Потому что нельзя просто добавить новые контролы. Потому что свалка кода в дизайнере и куча пересекающихся областей видимости, которые друг к другу никакого отношения не имеют.

Добавлено через 1 минуту
Тяп-ляп продакшн, как я называю...

Добавлено через 2 минуты
Потом отсюда растёт извечный вопрос: "Аааааа, как убрать кнопки у TabPage!?" и костыли, убирающие эти кнопки.

0

Rius, значит, не говнокодерское решение, а удобное решение, подходящее для формы с небольшим количеством контролов.

0

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

0

да динамическое создание элементов это правильно, напрягает только позиционирование...

0

Slavok47, Вы не поняли.
Можно создать UserControl в дизайнере, как новый класс. В студии есть создание нового контрола.
На него накидать все что нужно.
И вот этот готовый наследник UserControl'а и создавать динамически.

Добавлено через 44 секунды
Для позиционирования его уже можно применять соответствующие контейнеры.

1

Rius, хм, да действительно не понял, буду разбираться

0

Defazze, При разработке GUI нужно придерживаться тех же правил, что и для любых других ООП обьектов, вы согласны? А раз так, то как же можно пихать на форму кучу совершенно разнородных обьектов, никак не связанных между собой? Это же нарушает и принцип инкапсуляции, и solid, и фактически является антипаттерном, god обьектом.

0

Storm23, С правилами ООП трудно не согласится ) Но почему мы решили, что форма предназначена для отображения разнородных объектов? Стандартная задача: есть некоторые UserSettings, разбитые по категориям. Представляют из себя по сути один плоский класс с набором свойств. Вот их мы и отображаем. Деление на категории - исключительно пользовательское удобство.

Я ж не говорю, что табы категорически лучше или хуже юзер-контролов. Для каждого подхода есть своя область применения.

0

Сообщение от Defazze Но почему мы решили, что форма предназначена для отображения разнородных объектов? Стандартная задача: есть некоторые UserSettings, разбитые по категориям. Представляют из себя по сути один плоский класс с набором свойств.

А вы часто делаете классы с сотнями свойств? Если число свойств перваливает за десяток, то это явный сигнал к декмопозиции на отдельные классы. Что в случае GUI означает создание отдельных UserControl.

Defazze, Slavok47, Смотрите как это должно быть:
На главной форме лежит один UserControl, содержащий в себе дерево - слева. И пустая панель - справа. Панель - ничего не содержит и является просто контейнером для панелей настроек.
Далее, код главной формы вообще ничего не содержит, кроме одного обработчика. Это обработчик события SelectedNodeChanged дерева. В это обработчике, форма очищает панель справа, и создает UserControl того типа, который передало ему дерево. Создав контрол, отображает его в панели справа. Все.
Таким образом, наша главная форма вообще никак не будет меняться, какие бы новые панели свойств мы не делали, как бы не менялось дерево или как бы не менялись панели свойств - UserControl-ы. Код нашей формы - не будет меняться. Мы его один раз сделали - и забыли о нем. Красиво?
Далее мы просто разрабатываем свои простые UserContol-ы для каждой категории настроек, которые будут инкапсулировать в себе логику и интерфейс каждой категории.

3

Сообщение от Storm23 Если число свойств перваливает за десяток, то это явный сигнал к декмопозиции на отдельные классы. Что в случае GUI означает создание отдельных UserControl.

А я с этим и не спорю.

Приведенное Вами решение - превосходное.

0

Сюда ещё можно добавить автопоиск контролов настройки через рефлексию или MEF, с формированием дерева. И будет зашибись.

0

Я понял принцип, спасибо!

0

Сообщение от Storm23 Красиво?

Красиво, но этот подход имеет ряд недостатков:

1) Возможно придется создавать целую папку UserControlов для каждой такой формы
2) Композиция главной формы во времени разработки ухудшается: мы не видим как UserControl выглядит внутри нашей формы до выполнения программы
3) Нет возможности переключения между панелями во времени разработки
4) Код формы наполняется кодом, который больше относится к сериализации/десериализации контролов. Это отвлекает от логики. Ведь есть специально обученные сериализаторы, пусть они занимаются свойствами контролов в специально отведенном для этого месте
5) Создание насыщенных панелей скажется на производительности
6) При переключении между панелями будут сбиваться такие свойства, как позиция скролла, выбранная ячейка в таблице и т.д. Пользователю придется заново это делать

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

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


Логика переключения между панелями при этом сводится к одной строчке:

или так (если нужно обращение по имени панели):
Надеюсь кому-нибудь поможет

1

Вот, кстати, обыкновенное говнокодерское решение.rar.
Только не вижу тут ни в дизайнере (точнее в файле Form1.Designer.cs) свалки ни кучи пересекающихся областей видимости. Все как в обычном TabControl. Или он тоже нарушает все принципы ООП и оправдание ему прототип или предупреждение оверинжиниринга???
А если нужно логику декомпозировать - никто не мешает те же UserControlы насоздавать и поместить их на вкладки.

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

2