Теперь в дизайнере (и не только) можно создавать и удалять различные View и задавать их свойства.
Добавил свойство ActiveView и событие ActiveViewChanged — их использование можно посмотреть на тестовой форме.
Еще не разобрался с докингом, анкором и сплиттерами, т.е. не знаю, как сделать так, чтобы это было по-человечески
Нуждаюсь в совете.
Здравствуйте, Al-Ko, Вы писали:
AK>Еще не разобрался с докингом, анкором и сплиттерами, т.е. не знаю, как сделать так, чтобы это было по-человечески AK>Нуждаюсь в совете.
А что конкренто не понятно?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Al-Ko, Вы писали:
AK>>Еще не разобрался с докингом, анкором и сплиттерами, т.е. не знаю, как сделать так, чтобы это было по-человечески AK>>Нуждаюсь в совете.
VD>А что конкренто не понятно?
1) должно ли влиять изменение свойств Dock или Anchor на значения свойств Location и Size у View?
2) как привязать к View сплиттер? Завести булевые свойства IView.HSplitter и IView.VSplitter? Как влияет наличие сплиттера на докинг?
3) уместен ли вообще в нашем случае докинг без сплиттера?
4) нужно ли нам вообще свойство Anchor?
5) при динамическом создании View путем передвижения вертикального сплиттера из крайней левой позиции или горизонтального сплиттера из крайней верхней позиции,
нужно ли создавать только один View, или создавать их столько, сколько имеется с другой стороны сплиттера?
PS
Нужно, наверное, переименовать View на VGView. В фреймворке есть какой-то enum View и теперь нужно давать для нашего View полное имя: RSDN.VirtualGrid.View.
Здравствуйте, Al-Ko, Вы писали:
AK>1) должно ли влиять изменение свойств Dock или Anchor на значения свойств Location и Size у View?
Думаю, что у View таких слойств вообще не должно быть.
AK>2) как привязать к View сплиттер? Завести булевые свойства IView.HSplitter и IView.VSplitter? Как влияет наличие сплиттера на докинг? AK>3) уместен ли вообще в нашем случае докинг без сплиттера? AK>4) нужно ли нам вообще свойство Anchor? AK>5) при динамическом создании View путем передвижения вертикального сплиттера из крайней левой позиции или горизонтального сплиттера из крайней верхней позиции, AK>нужно ли создавать только один View, или создавать их столько, сколько имеется с другой стороны сплиттера?
Вот что мне пришло на ум. View должны быть вложенными! То есть мы должны сделать у View два режима:
1. View отображает данные грида.
2. View является контейнером для других View.
При этом View будет поддерживать два дополнительных свойства:
1. Выравнивание: Влево/Вверх, Вправо/Вниз, Пропроциональное. Оно будет говорить о том, как View выравнивается в родительском View.
2. Направление выравнивания внутри View: Вертикальное, Горизонтальное. Оно определяет как будут распологаться вложенные View (если они будут добавлены во View).
Таким образом по умиолчанию мы создаем View и так ак в него не добавлено других View, то оно отображает данные. Далее при добавлении в него другого View, оно переходит в режим контейнера и начинает выравнивать другие View, а уже они начинают заниматься отображением. Так как View будут иметь рекурсивную структуру, мы сможем создавать вложенности любой сложности.
Например, мы создаем два вложенных View с вертикальным расположением. Потом в одном и них добавляем еще три, но уже с горизонтальным положением. И получается довольно наворочненный варинат.
Причем все это дело будет практически жить на докинге. Остается только сделать сплитеры с помощью которых пользователь сам смог бы разделять View и вуаля!
AK>PS AK>Нужно, наверное, переименовать View на VGView. В фреймворке есть какой-то enum View и теперь нужно давать для нашего View полное имя: RSDN.VirtualGrid.View.
VG как-то не хорошо. Давай уж тогда GridVieu. А то, во-первых, непонятное сокращение, а во-вторых, при использовании в конкретном гриде будет выглядить по дурацки.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Вот что мне пришло на ум. View должны быть вложенными! То есть мы должны сделать у View два режима: VD>1. View отображает данные грида. VD>2. View является контейнером для других View.
Не нравится мне такой подход. У нас уже есть контейнер — ПАЛ-контрол. Вот в него View и вкладываются. Во вкладывании одного View в друнгой я не вижу ни физического смысла, ни преимуществ (но трудности) для прикладника.
Я бы определил следующие правила:
1) Вся клиентская поверхность ПАЛ-контрола всегда должна быть заполнена.
2) Новые View могут возникать только у границ ПАЛ-контрола
3) При создании View у границы можно выбрать варианты:
— либо он занимает всю границу ПАЛ-контрола и отодвигает все примыкавшие ранее к этой границе View
— либо он "пристраивается" c одного или другого края в тот же ряд или ту же колонку, где находятся все примыкавшие ранее к этой границе View.
Таким образом, его докинг, или вернее все-таки Anchor будет выражаться следующими значениями:
Top
Bottom
Left
Right
Top, Left
Top, Right
Left, Top
Left, Bottom
Right, Top
Right, Bottom
Bottom, Left
Bottom, Right
Все View будут автоматически докированы к нижней и правой области, с тем, чтобы при расширении грида в эти стороны у примыкающих к ним View становились видимыми новые ячейки.
Затем, ввести свойство наличия сплиттеров во всем гриде, принимающих значение:
None,
Inner — сплиттеры имеются только между смежными View, чтобы пользователь мог менять размеры созданных View
All — кроме варианта Inner, сплиттеры имеются еще по левой и верхней границам окна ПАЛ-контрола, чтобы пользователь мог создавать View, перемещая эти сплиттеры от границ (ну, как в Экселе)
И все. Больше ничего не нужно. Я думаю, что описанные тобой "гроздья" View в жизни не пригодятся — сам прикинь.
VD>VG как-то не хорошо. Давай уж тогда GridVieu. А то, во-первых, непонятное сокращение, а во-вторых, при использовании в конкретном гриде будет выглядить по дурацки.
Переименовал класс View на GridView. А интерфейс IView тоже переименовывать?
Здравствуйте, Al-Ko, Вы писали: VD>>2. View является контейнером для других View.
AK>Не нравится мне такой подход. У нас уже есть контейнер — ПАЛ-контрол. Вот в него View и вкладываются. Во вкладывании одного View в друнгой я не вижу ни физического смысла, ни преимуществ (но трудности) для прикладника.
Э... тут ты не прав. Приемущества очевидны. Просто ты их не рассмотрел. Попробую растолковать...
Итак, как нам сделать гибкую систему разделения окна ВЦ да так чтобы ее было легко настроить?
Можно придумть конечно некий формат вроде HTML-таблицы, в котором "рисовать" нужное нам разделение. Например, вот такую структуру:
Можно описать средствами хтмл. Но сделать это не так то просто. К тому же ее мало описать, ее нужно еще и итерпретировать. А ведь каждая рамка может быть сплитером, а стало быть двигаться пользователем.
Испльзовать для этого возможности докинга винформсов будет не так то просто. Ведь докинг работает по очень примитивной схеме. Он позволяет выровнять окна или по вертикали, или по горизонтали. Для создания сложного докинга в винформсах используют промежуточные окна которые вклаываются друг в друга. Например, описанную выще схему можно реализовать так:
1. Сначал создать подложку:
В нее поместить два вложенных окна (между которыми разместить сплитер):
+-------------------+---------------+
| |
| +
| А |
| +
| |
+-------------------+---------------+
| Б |
+-----------------------------------+
Далее в окно А поместить еще два окна со сплитером:
+-------------------+---------------+
| | |
| | |
| В | Г +
| | |
+-------------------+---------------+
| Б |
+-----------------------------------+
Ну, и последним штрихом поместить в окно Г еще три окна со сплитерами, но на этот раз с вертикальным, а не горизонтальным выравниванием:
+-------------------+---------------+
| | Д |
| +---------------+
| В | Е |
| +---------------+
| | Ж |
+-------------------+---------------+
| Б |
+-----------------------------------+
Собственно именно так и делается сейчас в винформсах.
Собственно так как физически вью — это и есть контролы винформс, то ничего и делать не прийдется. Нужно только прикрутить интерфейс и позволить им управлять. Вложенные вью, по-моему, было бы самым простым и удобным решением.
Кстати, по тому же принципу можно было бы построить и формирование строк со сложным расположением ячеек. Только вложенность уже была бы виртуальной.
AK>Я бы определил следующие правила: AK>1) Вся клиентская поверхность ПАЛ-контрола всегда должна быть заполнена.
Ну, это само собой.
AK>2) Новые View могут возникать только у границ ПАЛ-контрола
Гы. Это уже нарушает правило 1 из твоего списка. Вью, если оно одно должно занимать всю площать родительского окна (или вью).
AK>3) При создании View у границы можно выбрать варианты: AK> — либо он занимает всю границу ПАЛ-контрола и отодвигает все примыкавшие ранее к этой границе View
Ну, и как создать вариант описанный мною выше? Ты же сможешь создать или вертикальный или горизонтальный набор вьюх. Но сложную компоновку получить не удастся.
AK> — либо он "пристраивается" c одного или другого края в тот же ряд или ту же колонку, где находятся все примыкавшие ранее к этой границе View.
А откуда взялись все эти ряды и колонки?
AK> Таким образом, его докинг, или вернее все-таки Anchor будет выражаться следующими значениями:
AK> Top AK> Bottom AK> Left AK> Right AK> Top, Left AK> Top, Right AK> Left, Top AK> Left, Bottom AK> Right, Top AK> Right, Bottom AK> Bottom, Left AK> Bottom, Right
AK>Все View будут автоматически докированы к нижней и правой области, с тем, чтобы при расширении грида в эти стороны у примыкающих к ним View становились видимыми новые ячейки.
Невозможно сделать одновременно якоря (анчеры) и докинг. Или то или другое. И анчеры тут совсе не подходят (именно в соотвествии с пунктом 1).
AK>Затем, ввести свойство наличия сплиттеров во всем гриде, принимающих значение:
AK>None, AK>Inner — сплиттеры имеются только между смежными View, чтобы пользователь мог менять размеры созданных View AK>All — кроме варианта Inner, сплиттеры имеются еще по левой и верхней границам окна ПАЛ-контрола, чтобы пользователь мог создавать View, перемещая эти сплиттеры от границ (ну, как в Экселе)
AK> И все. Больше ничего не нужно. Я думаю, что описанные тобой "гроздья" View в жизни не пригодятся — сам прикинь.
Я думаю, что это буде и проще и удобнее. Твой план даже не намекает на реализацию. Я же предлагаю почти готовую реализацию в которой можно будет использовать докинг и спрлитеры винформсов. Что касается практики, то — это проблемы пользователей. Не нужно им бдет сложной иерархии сплитеров — пусть не делают. Могут вообще без сплитеров обойтись, а могут и десяток зафигачить.
Рекурсивность хороша тем, что достаточно сделать одну ветку, как ты получишь иерархию автоматически. Так что не пугайся. Объемы работы будут очень небольшими. Это только выглядет пугающе.
AK>Переименовал класс View на GridView. А интерфейс IView тоже переименовывать?
В принципе для единообразия можно было бы.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, по тому же принципу можно было бы построить и формирование строк со сложным расположением ячеек. Только вложенность уже была бы виртуальной.
Тоже интересно
AK>>Я бы определил следующие правила: AK>>1) Вся клиентская поверхность ПАЛ-контрола всегда должна быть заполнена.
VD>Ну, это само собой.
AK>>2) Новые View могут возникать только у границ ПАЛ-контрола
VD>Гы. Это уже нарушает правило 1 из твоего списка.
абсолютно нет VD>Вью, если оно одно должно занимать всю площать родительского окна (или вью).
я здесь говорю о том, что вновь созданный View должен всегда касаться какой либо границы ПАЛа
AK>>3) При создании View у границы можно выбрать варианты: AK>> — либо он занимает всю границу ПАЛ-контрола и отодвигает все примыкавшие ранее к этой границе View
+-------------------+---------------+
| | Д |
| +---------------+
| В | Е |
| +---------------+
| | Ж |
+-------------------+---------------+
| Б |
+-----------------------------------+
VD>Ну, и как создать вариант описанный мною выше? Ты же сможешь создать или вертикальный или горизонтальный набор вьюх. Но сложную компоновку получить не удастся.
Да уж конечно
Сперва создаешь Д, Е и Ж с докингом Top
Потом В с докингом Left
Потом Б с докингом Bottom
AK>> — либо он "пристраивается" c одного или другого края в тот же ряд или ту же колонку, где находятся все примыкавшие ранее к этой границе View.
VD>А откуда взялись все эти ряды и колонки?
см.пример выше
VD>Невозможно сделать одновременно якоря (анчеры) и докинг. Или то или другое. И анчеры тут совсе не подходят (именно в соотвествии с пунктом 1).
значит, я оговорился. Речь идет о докинге.
VD>Я думаю, что это буде и проще и удобнее. Твой план даже не намекает на реализацию.
надо не намекать, а делать
Потом, у тебя в коллеции одни View будут изображать грид, а вторые — содержать другие View. Т.е.для пяти изображений грида ты создаешь 8 View.
А как ты будешь различать, какие показывают грид, а какие View? Да не, нелогично это все.
VD>Я же предлагаю почти готовую реализацию в которой можно будет использовать докинг и спрлитеры винформсов. Что касается практики, то — это проблемы пользователей. Не нужно им бдет сложной иерархии сплитеров — пусть не делают. Могут вообще без сплитеров обойтись, а могут и десяток зафигачить. VD>Рекурсивность хороша тем, что достаточно сделать одну ветку, как ты получишь иерархию автоматически. Так что не пугайся. Объемы работы будут очень небольшими. Это только выглядет пугающе.
Нас таким не запугаешь Но пока это выглядит просто не очень логично.
AK>>Переименовал класс View на GridView. А интерфейс IView тоже переименовывать? VD> В принципе для единообразия можно было бы.
Так, где там наше "Replace All"?
Здравствуйте, Al-Ko, Вы писали:
VD>>Гы. Это уже нарушает правило 1 из твоего списка. AK>абсолютно нет
Или да, или тебе прийдется наворачивать сложную схему выравнивания.
VD>>Вью, если оно одно должно занимать всю площать родительского окна (или вью). AK>я здесь говорю о том, что вновь созданный View должен всегда касаться какой либо границы ПАЛа
Гы. Трех, а не одной. Если мы говорим о докинге. А если нет, то опиши схему выравнивания более подробно. Потому как я ее от тебя вообще не слышал.
AK>Да уж конечно
AK>Сперва создаешь Д, Е и Ж с докингом Top AK>Потом В с докингом Left AK>Потом Б с докингом Bottom
Ладно. Предположим. Но описанным тобой образом добиться нужного расположения не дуастся. Причем чтобы выставить контролы наместо нужно долго трахаться с выставлением Z-ордера, а реально скорее всего прийдется править код вручную. Как ты предлагаешь сделать настройку расположения вью в ВГ? Попробуй сделать простенький тестик позволяющий в рантайме поменять расположение контролов эмулирующих вью. Ну, то есть ппродумать как будет выглядеть программынй и графический интерфейсы.
VD>>Невозможно сделать одновременно якоря (анчеры) и докинг. Или то или другое. И анчеры тут совсе не подходят (именно в соотвествии с пунктом 1). AK>значит, я оговорился. Речь идет о докинге.
ОК. Сделай пример о котором я говорил выше. Потом обсудим. Сейчас информации слишком мало. Может ты и прав.
VD>>Я думаю, что это буде и проще и удобнее. Твой план даже не намекает на реализацию. AK>надо не намекать, а делать
Трясти надо? Как в анегтоте про безьяну и прапора?
AK>Потом, у тебя в коллеции одни View будут изображать грид, а вторые — содержать другие View. Т.е.для пяти изображений грида ты создаешь 8 View. AK>А как ты будешь различать, какие показывают грид, а какие View? Да не, нелогично это все.
А зачем различать? Те что перекрыты просто никогда не будут отрисовываться.
В общем, я боюсь что будут проблемы как с программной настройкой, так и с визуальной.
AK>Нас таким не запугаешь Но пока это выглядит просто не очень логично.
Что выглядит нелогичным?
AK>Так, где там наше "Replace All"?
Кстати, может на новую студию перейти? Там рефакторинг есть. Если полная студия недоступна, то можно использовать эксресс (~30 метров).
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, может на новую студию перейти? Там рефакторинг есть. Если полная студия недоступна, то можно использовать эксресс (~30 метров).
дык это студия, а МСДН? там уже все гораздо сложнее
Я вот прикидывал и твой вариант, и мой по добавлению/удалению View. Оба мне не нравятся, если честно. Может, поступить вообще так:
— по умолчанию, после загрузки контрола мы имеем всегда один View, заполняющий всю область ПАЛ-контрола.
— вся площадь ПАЛ-контрола должна быть заполнена View.
— новый View может быть добавлен только делением выбранного View на две части — либо по вертикали, либо по горизонтали. Это можно осуществить методом Split, возвращающим индекс вновь созданного View. При этом созданный View помещается непосредственно в коллекцию Views.
— соответственно, прикладник не имеет права добавлять в коллекцию Views методами Add/Insert (а только методом Split)
— по умолчанию, View делится пополам. При горизонтальном сплите новый View помещается, допустим, снизу, а при вертикальном — справа. Пользователю дается право менять этот порядок, а также изменять координаты границы.
Рассматривая твой пример, получаем
1. Сначал создать подложку:
+-------------------+---------------+
| |
| +
| А |
| она создается автоматом +
| |
+ +
| |
+-----------------------------------+
+-------------------+---------------+
| |
| +
| А |
| к View А применяем метод Split +
| горизонтальный |
+-------------------+---------------+
| появляется View Б |
+-----------------------------------+
+-------------------+---------------+
| | |
| А | появляется |
| а теперь вертикаль| В +
| ный |
+-------------------+---------------+
| Б |
+-----------------------------------+
Ну, и последним штрихом View B делим на два, а потом View Г еще раз, выравнивая размеры.
+-------------------+---------------+
| | В |
| +---------------+
| А | Г |
| +---------------+
| | Д |
+-------------------+---------------+
| Б |
+-----------------------------------+
Итого, имеем пять View, а не восемь, как в случае с рекурсией View. Все View имеют постоянный докинг, и пользователь вообще не заморачивается на докинг или якорение. Что скажешь?
Здравствуйте, Al-Ko, Вы писали:
AK>Это можно осуществить методом Split, возвращающим индекс вновь созданного View.
Это плохое решение, так как оно идет в разрез с принятыми в дотнете нормами. В дотнете принято описывать модель в терминах объектной модели (ОМ), т.е. графа обхектов различных типов связанных между собой. Наборы принято оформлять в коллекции... Опять же при твоем подходе будут проблемы с сериализацией.
AK> При этом созданный View помещается непосредственно в коллекцию Views.
И как потом программно разобрать стркутуру всех этих вью?
AK>- по умолчанию, View делится пополам. При горизонтальном сплите новый View помещается, допустим, снизу, а при вертикальном — справа. Пользователю дается право менять этот порядок, а также изменять координаты границы.
Ну, и что это даст? Не, ты конечно можешь сделать такие метод. В этом проблем нет. Но что даст отсуствие нормльного подхода поволяющего собрать нужную конфигурацию вью?
AK>
AK>+-------------------+---------------+
AK>| | |
AK>| А | появляется |
AK>| а теперь вертикаль| В +
AK>| ный |
AK>+-------------------+---------------+
AK>| Б |
AK>+-----------------------------------+
AK>
А как перед этим делением плучить нужный вью, если учесть, что имеется сложная структура?
AK>Итого, имеем пять View, а не восемь, как в случае с рекурсией View. Все View имеют постоянный докинг, и пользователь вообще не заморачивается на докинг или якорение. Что скажешь?
Не думаю, что есть разница солько этих вью будет. Ты лучше продумай все нюансы. Мне пока вообще не ясно:
1. Как будет проходить сериализация и десериализация как отдельных вью, так и их иерархии? В случае общепринятой ОМ все просто. Будут объекты и их коллекции. Граф вью определяет структуру и сериализация происходит автоматически штатными стредствами дотнета.
2. Как добраться до конкретного вью? Опять же в случае с классикой все ясно. У тебя пока нет. Особенно не ясно как их индентифицировать в случае модификации структуры. Ведь добавление или удаление одного вью может поменять индексы всех оставшихся.
3. Насколько без вложенности будет можно обеспечить нужные характеристики докинга для подвью? Другими словами, можно ли будет, например, сделать докинг "fill" для вложенного набора вью (ну, к примеру, для вью "Д" из твоего последнего примера.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Al-Ko, Вы писали:
AK>>Это можно осуществить методом Split, возвращающим индекс вновь созданного View.
VD>Это плохое решение, так как оно идет в разрез с принятыми в дотнете нормами. В дотнете принято описывать модель в терминах объектной модели (ОМ), т.е. графа обхектов различных типов связанных между собой. Наборы принято оформлять в коллекции... Опять же при твоем подходе будут проблемы с сериализацией.
Ну почему будут проблемы? Коллекция-то физически останется. Split ведь будет вызывать
new View(
ParentView, //от которого пошло деление
SplitMode, //верт. или гориз. сплит
SplitPosition //координаты границы
)
а потом добавлять в коллекцию при помощи Views.Add, в конце концов. Тут этот Split, пожалуй и не так важен, т.е. он идет как вспомогательный метод. Вью будут добавляться в коллекцию обычным образом.
У каждого View будет ссылка на тот, от которого он отпочковался. Похоже на твою идею, но без вложенности.
AK>> При этом созданный View помещается непосредственно в коллекцию Views. VD>И как потом программно разобрать стркутуру всех этих вью?
см.выше
VD>А как перед этим делением плучить нужный вью, если учесть, что имеется сложная структура?
см.выше — View будет иметь ссылку на тот, от которого он образован, да и его "родителю" можно давать ссылку на того, который от него отпочковался в методе Add коллекции. Т.е. получается, мы имеем дело с двухсвязным списком. Дотнет умеет с ним работать?
VD>Не думаю, что есть разница солько этих вью будет. Ты лучше продумай все нюансы. Мне пока вообще не ясно: VD>1. Как будет проходить сериализация и десериализация как отдельных вью, так и их иерархии?
для этого примера:
+-------------------+---------------+
| | В |
| +---------------+
| А | Г |
| +---------------+
| | Д |
+-------------------+---------------+
| Б |
+-----------------------------------+
где первый параметр конструктора View — порядковый индекс View, от которого образовался очередной.
В методах Add и AddRange коллекции при десериализации расставлять необходимые ссылки не на индексы, а на физические View, а в методе Remove корректировать их. VD>В случае общепринятой ОМ все просто. Будут объекты и их коллекции. Граф вью определяет структуру и сериализация происходит автоматически штатными стредствами дотнета.
VD>2. Как добраться до конкретного вью? Опять же в случае с классикой все ясно.
Ну как тебе сказать... Вот какой индекс у твоего View Д ?(см.самую последнюю картинку ниже — это твоя картинка). Вот я захотел, чтобы вью Д стал родительским и в нем было создано еще два вью. Как мне до него добраться? VD>У тебя пока нет.
VD>Особенно не ясно как их индентифицировать в случае модификации структуры. Ведь добавление или удаление одного вью может поменять индексы всех оставшихся.
а как это дело (изменение структуры и вследствие этого индексов) решается в классике? Вот, допустим, по твоей модели,
если ты удалишь вью Б, то какие индексы будут иметь вью Г, Д, Е и Ж? (я процитирую кусок твоего более раннего сообщения)
VD>Далее в окно А поместить еще два окна со сплитером:
+-------------------+---------------+
| | |
| | |
| В | Г +
| | |
+-------------------+---------------+
| Б |
+-----------------------------------+
VD>Ну, и последним штрихом поместить в окно Г еще три окна со сплитерами, но на этот раз с вертикальным, а не горизонтальным выравниванием:
+-------------------+---------------+
| | Д |
| +---------------+
| В | Е |
| +---------------+
| | Ж |
+-------------------+---------------+
| Б |
+-----------------------------------+
[конец цитаты]
VD>3. Насколько без вложенности будет можно обеспечить нужные характеристики докинга для подвью? Другими словами, можно ли будет, например, сделать докинг "fill" для вложенного набора вью (ну, к примеру, для вью "Д" из твоего последнего примера.
А как он должен, этот вью "Д" из моего примера себя вести в случае "fill"?
Я боюсь, как бы не пришлось делать для мульти-View Columns и Rows и Spawn, как это намечено в TableLayoutPanel из FW 2.0.
Здравствуйте, Al-Ko, Вы писали:
AK>Ну почему будут проблемы? Коллекция-то физически останется. Split ведь будет вызывать
AK>
AK>new View(
AK>ParentView, //от которого пошло деление
AK>SplitMode, //верт. или гориз. сплит
AK>SplitPosition //координаты границы
AK>)
AK>
Какие еще ParentView? Или список плоский и никакий ParentView, или по моему сценарию иерархия вложенностей вью.
AK>а потом добавлять в коллекцию при помощи Views.Add,
Ты же говорил, что с помощью Add их добавить нельзя? Да и зачем делать два действия?
AK> в конце концов. Тут этот Split, пожалуй и не так важен, т.е. он идет как вспомогательный метод.
Как вспомогательный — нет проблем. Но ты опиши полную концепцию объектной модели. А то я пока что так и не увидил полного решения.
AK> Вью будут добавляться в коллекцию обычным образом.
Мне кажется тут может быть только две модели. Первая — плоская — без вложенности основанная на порядке располжения и типах докинга вью. Вторая — иерархическая (как предлагал я). В ней каждый уровень примитивен, а сложная структура получается путем вложений одних вью в другие.
Методы вроде разделения конечно возможны, но это уже синтаксический сахар, т.е. средства урпощения работы (не более того).
Мне кажется, что иерархическое решение будет проще в использовании (особенно при модификации) и более гибко, так как у сложного докинга есть некоторые ограничения (напримаер, нельзя создать более одного контрола у которого установлен тип докинга "Fill".
AK>У каждого View будет ссылка на тот, от которого он отпочковался.
Это невозможно реализовать при использовании плоского докинга. Максимум чем ты сможешь оперировать — это последовательностью вью в списке (так же как докинком управляет расположение котролов в контейнере).
AK>Похоже на твою идею, но без вложенности.
1. Я не вижу как ты этого добьешся. Ну, да не беда потрахавшись ты и сам это поймешь.
2. Зачем эмулировать вложенность если можно сделать просто сделать вью вложенными. Это резко упростит реализацию. Вью просто будет контейнером (и все).
VD>>И как потом программно разобрать стркутуру всех этих вью? AK>см.выше
К сожалению ты так этого и не описал. Ты говоришь о каких-то гипотетических парентах, но как это будет реализовано физически не говоришь. Зная устройство докинга в винформсах я не вижу как ты этого доьешся.
VD>>А как перед этим делением плучить нужный вью, если учесть, что имеется сложная структура? AK>см.выше -
Еще раз. Если бы я видел ответ и он меня удовлетворил бы, то я бы просто не задавал вопрос. Так что лучше не отсылай меня неизвесно куда.
AK> View будет иметь ссылку на тот, от которого он образован, да и его "родителю" можно давать ссылку на того, который от него отпочковался в методе Add коллекции. Т.е. получается, мы имеем дело с двухсвязным списком.
Что-то мне все это напоминает сказку "Салдатская каша", ну, ту в которой салдат кашу из топора ворил. Типа добавить овса, соли, сахара и т.п. (парента и коллекцию чаилодов и т.п.) и получится каша. Может проще варить кашу сразу по человесески? Ведь зачем делать какие-то виртуальные паренты если они уже есть в контролах? И список вложенных компонетоов есть.
Эмуляция приведет к тому что следующим шагом ты начнеш боросться с проблемами вроде того, что догинг будет зависить от положения контролов в списке (т.е. от порядка из создания). А зачем это?
AK>Дотнет умеет с ним работать?
Дотнет ничего не умеет. Это просто сдеда выполнения в которой можно сделать все что угодно.
AK>ты думаешь, так не получится сделать:
AK>
AK>this._simpleGrid.Views.AddRange(new RSDN.VirtualGrid.GridView[] {
AK> new RSDN.VirtualGrid.GridView(-1 ), // создался А
AK> new RSDN.VirtualGrid.GridView(0, horz), // создался Б
AK> new RSDN.VirtualGrid.GridView(0, vert), // создался В
AK> new RSDN.VirtualGrid.GridView(2, horz), // создался Г
AK> new RSDN.VirtualGrid.GridView(3, horz)}) // создался Д
AK>
AK>где первый параметр конструктора View — порядковый индекс View, от которого образовался очередной.
И где тут информация о парентах о которой ты говорил? Да и все эти цифру тут в общем-то не нужны. На докинг будет влиять исключительно порядок добавления контролов.
Получается естественным способом управления структурой вью будет изменение их положения в контейнере. Но так как это дико неудобно ты будешь вынужден эмулировать интерфейс так как-будто вью вложены друг в друга. Вот только зачем? Да и как? Ведь фактической вложенности нет и парентом будет указать негого.
AK>В методах Add и AddRange коллекции при десериализации расставлять необходимые ссылки не на индексы, а на физические View, а в методе Remove корректировать их.
Ну, и зачем все это? Почему все же просто не сделать их вложенными?
Есть такое правило. Высказанное Инштейном (вроде бы). "Все должно быть как можно проще, но не проще." (вроде так). В данном случае проще сдалать иерарцию, а не эмулировать ее. Ты пыташся сдалать проще, но на самом деле усложняешь. Ну, а эконамия двух трех окон никому не нужна. На это можно смело забить.
AK>Ну как тебе сказать... Вот какой индекс у твоего View Д ? (см.самую последнюю картинку ниже — это твоя картинка).
Это вроде бы я у тебя спрашиваю. В иерархическом варианте все будет очень просто:
grid.Views[0][1][2]
0 — это вью содернжащее в себе (А, (В, Г, Д)).
1 — Это вью (В, Г, Д)
2 — Это вью (Д).
Причем если я вставлю в корневой вью перед Б еще один вью (Е), то индексы не изменятся. А вот если ты будешь эмулировать иерархию, то тебе прийдется произвести пересчет сквозных индексов. В общем все будет сложнее. А зачем неясно.
AK> Вот я захотел, чтобы вью Д стал родительским и в нем было создано еще два вью. Как мне до него добраться?
В иерархическом варианте нет проблем:
View е = new View();
View ж = new View();
grid.Views[0][1][2].AddRang(е, ж);
а вто в плоском?
AK>а как это дело (изменение структуры и вследствие этого индексов) решается в классике?
Дык в классике нет общей коллекции и хитрых зависимостей между ее индексами и виртуальными. В ней есть просто набор отдельных коллекций вложненных друг в друга. А с ними работать намного проще. Если изменение и происходит, то только в предалах одной коллекции и его не трудно отследить (пересчитывать то ничего не надо).
AK> Вот, допустим, по твоей модели, AK>если ты удалишь вью Б, то какие индексы будут иметь вью Г, Д, Е и Ж? (я процитирую кусок твоего более раннего сообщения)
Те же самые. Вот если удалить вью в котором находятся А, В, Г, Д, то индекс Б изменится. Но это уже не так сложно для сознания. Глвано, что наличие скрытых от пользователя парентов позволяет не менять других индексов в других коллекциях. Так же важно, что нет никаких пересчетов из глобального индекса в виртуальные.
VD>>3. Насколько без вложенности будет можно обеспечить нужные характеристики докинга для подвью? Другими словами, можно ли будет, например, сделать докинг "fill" для вложенного набора вью (ну, к примеру, для вью "Д" из твоего последнего примера.
AK>А как он должен, этот вью "Д" из моего примера себя вести в случае "fill"?
В и Г должны прижиматься к верхнему краю, а Д занимать всю оставшуюся площать упираясь с права в А, снизу в Б, а слева в левую границу грида.
AK>Я боюсь, как бы не пришлось делать для мульти-View Columns и Rows и Spawn, как это намечено в TableLayoutPanel из FW 2.0.
С вложенным вариантом проблем не будет. Строки нафиг не упали, а отступы можно сделать просто указав их у контролов реализующих вью.
AK>В общем, пока одни белые пятна
Незнаю. Мне кажется с иерархическим подходмо все просто и ясно. Белые пятна как раз в плостом варианте. И все это из-за попытке сэкономить пару окон.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ты меня почти убедил.
AK>>Ну как тебе сказать... Вот какой индекс у твоего View Д ? (см.самую последнюю картинку ниже — это твоя картинка). VD>Это вроде бы я у тебя спрашиваю. В иерархическом варианте все будет очень просто: VD>
VD>grid.Views[0][1][2]
VD>
Погоди, погоди, просто... Ничего не просто!
Смотрим все сначала (цитирую и ставлю индексы):
Ну, и последним штрихом поместить в окно Г еще три окна со сплитерами, но на этот раз с вертикальным, а не горизонтальным выравниванием:
+-------------------+---------------+
| | Д [0,1,0] |
| +---------------+
| В | Е [0,1,1] |
| [0,0] +---------------+
| | Ж [0,1,2] |
+-------------------+---------------+
| Б [1] |
+-----------------------------------+
А, я понял. Хотя я сказал: смотри на картинку ниже, ты посмотрел на ту, что выше. Ты говоришь про Д, который в твоем и этом примере Ж.
Но вот в этом примере вообще нельзя однозначно расставить индексы для Б, В и Г:
+-------------------+---------------+-------------------+
| | Б | |
| +---------------+ +
| A | В | Д |
| +---------------+ +
| | Г | |
+-------------------+---------------+-------------------+
Вот допустим, ты прикладник, получивший в наследство такой грид, и тебе надо обратиться к Вью Г.
Ты можешь сказать, что Г имеет индекс [1,2]. А я тебе могу сказать, что Г имеет индекс [0,1,2] или [1,0,2], в зависимости от порядка добавления View. Или даже [1,1,1]. А ведь порядка создания View никто не знает. Ну и как быть? Есть неоднозначности.
[0] [1]
+-------------------+---------------+-------------------+
| | Б [1,0,0]| |
| +---------------+ +
| A[0] | В [1,0,1]| Д [1,1] |
| +---------------+ +
| | Г [1,0,2]| |
+-------------------+---------------+-------------------+
[1,0] [1,1]
AK>>Я боюсь, как бы не пришлось делать для мульти-View Columns и Rows и Spawn, как это намечено в TableLayoutPanel из FW 2.0. VD>С вложенным вариантом проблем не будет. Строки нафиг не упали, а отступы можно сделать просто указав их у контролов реализующих вью.
В общем, с иерархическим построением я согласен. Но пока есть неоднозначности в индексации сложных конструкций.
В принципе для единообразия можно было бы.
Ты говоришь про Д, который в твоем и этом примере Ж.