Теперь в дизайнере (и не только) можно создавать и удалять различные 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>С вложенным вариантом проблем не будет. Строки нафиг не упали, а отступы можно сделать просто указав их у контролов реализующих вью.
В общем, с иерархическим построением я согласен. Но пока есть неоднозначности в индексации сложных конструкций.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Al-Ko, Вы писали:
VD>Замени в своих рассуждениях плоские массивы на вложенные множества и все станет намного понятнее. Пиши так: VD>
VD>А(Б(Г(), Д(), Ж()), В())
VD>
VD>и все будет понятно. Выкинув буквы ты получишь чистые множетсва. VD>
VD>(((), (), ()), ())
VD>
VD>к которым можно обращаться по индексам.
VD>Так доступ к Ж будет выглядеть как: VD>
VD>Views[0][2]
VD>
VD>или: VD>
VD>Б.Ж
VD>
я не понял о чем ты здесь.
У меня есть вопрос по другому примеру:
Но вот в этом примере вообще нельзя однозначно расставить индексы для Б, В и Г:
+-------------------+---------------+-------------------+
| | Б | |
| +---------------+ +
| 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>С вложенным вариантом проблем не будет. Строки нафиг не упали, а отступы можно сделать просто указав их у контролов реализующих вью.
В общем, с иерархическим построением я согласен. Но пока есть неоднозначности в индексации сложных конструкций.
Здравствуйте, Al-Ko, Вы писали:
AK>я не понял о чем ты здесь.
О исходном примере.
AK>У меня есть вопрос по другому примеру:
AK>Но вот в этом примере вообще нельзя однозначно расставить индексы для Б, В и Г:
AK>
AK>+-------------------+---------------+-------------------+
AK>| | Б | |
AK>| +---------------+ +
AK>| A | В | Д |
AK>| +---------------+ +
AK>| | Г | |
AK>+-------------------+---------------+-------------------+
AK>
Чё ж это нельзя? Только сначала нужно все немножко уточнить. Дело в том, что ты упустил из виду подложку (Б, В, Г). Перерисуем твой пример так чтобы все было видно:
+-------------------+------ Б ------+-------------------+
| | В | |
| +---------------+ +
| A | Г | Е |
| +---------------+ +
| | Д | |
+-------------------+---------------+-------------------+
Где Б — это подложка для (И, Г, Д). И спокойно ответим на вопрос.
Запись в виде множеств будет выглядеть так: (А, Б(В, Г, Д), Е).
Индекс, например, для Г будет такой: View[1][1].
AK>Вот допустим, ты прикладник, получивший в наследство такой грид, и тебе надо обратиться к Вью Г.
Г у тебя — это Д у меня. Так что индекст будет View[1][2].
AK>Ты можешь сказать, что Г имеет индекс [1,2].
После уточнения несомненно.
AK> А я тебе могу сказать, что Г имеет индекс [0,1,2] или [1,0,2], в зависимости от порядка добавления View.
Это если в твоей системе. Я как раз против сквозной индексации.
AK> Или даже [1,1,1]. А ведь порядка создания View никто не знает. Ну и как быть? Есть неоднозначности.
Ну, что-то у тебя вообще какой-то рандом попер.
AK>
AK>+-------------------+---------------+-------------------+
AK>| | Б [1,0] | |
AK>| +---------------+ +
AK>| A[0] | В [1,1] | Д [2] |
AK>| +---------------+ +
AK>| | Г [1,2] | |
AK>+-------------------+---------------+-------------------+
AK>
Еще раз настоятельно рекомендую не думать в терминах плоского или многомерного массива. Это вредно для мозгов.
AK>В общем, с иерархическим построением я согласен.
Ну, уже хорошо. Значит появляется единое мнение.
AK>Но пока есть неоднозначности в индексации сложных конструкций.
Дык на то мы тут и общаемся, чтобы вопросы возникали у нас, а не у тех кто будет потом с этим возиться. Я как раз сторонник того, чтобы ставить на первое метсо не простоту разработки, а простоту последующего использования (даже в ущерб потребляемым ресурсам и скорости (в разумных пределах, конечно)).
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
вот теперь у данного View индекс [0,1,2]. А если в пункте 2 добавлять новые в правый вью, то индекс нашего элемента будет [1,0,2]. А если еще учитывать, что в средний вью может добавляться не сразу три, а два вью, и потом один из них включит в себя два, то индекс будет вообще [1,1,1]. Короче, внешний вид один и тот же, а индекс может быть абсолютно разным. Вот только это мне и не нравится в данном подходе. А как с этим бороться — не представляю. Остается только при помощи строк, колонок и объединений? AK>>Но пока есть неоднозначности в индексации сложных конструкций. VD>Дык на то мы тут и общаемся, чтобы вопросы возникали у нас, а не у тех кто будет потом с этим возиться. Я как раз сторонник того, чтобы ставить на первое метсо не простоту разработки, а простоту последующего использования (даже в ущерб потребляемым ресурсам и скорости (в разумных пределах, конечно)).
Я тоже.
Здравствуйте, Al-Ko, Вы писали:
AK>я специально оставил цитирование чтобы было понятнее.
Не надо так делать. Я с успехом могу залесть на сообщение выше.
AK>Я считаю, что далеко не так все однозначно в этом примере. И этот, как ты говоришь, рандом может возникнуть в зависимости от порядка добавления вью.
Еще раз прошу не использовать натацию многомерного массива, а использовать натацию вложенных множеств. Тогда пробем с пониманием будет меньше.
AK>вот теперь у данного View индекс [0,1,2]. А если в пункте 2 добавлять новые в правый вью, то индекс нашего элемента будет [1,0,2]. А если еще учитывать, что в средний вью может добавляться не сразу три, а два вью, и потом один из них включит в себя два, то индекс будет вообще [1,1,1]. Короче, внешний вид один и тот же, а индекс может быть абсолютно разным. Вот только это мне и не нравится в данном подходе. А как с этим бороться — не представляю. Остается только при помощи строк, колонок и объединений?
Т.е. тебя смущает, что одного внешнего вида можно будет добиться разными путями? Дык не стоит этого бояться. Главнео чтобы не путался программист. К тому же хотя они будут эквавалентны по внешнему виду, по функциональности они будут различаться. Ведь при масштабировании они будут вести себя по разнмоу. Одна из панелей ведь обязана быть выровнена влево/вправо, а другая заполнять все оставшееся пространство. И вложенные элементы так же будут вести себя по разному в зависимости от того куда они вложены.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Еще раз прошу не использовать натацию многомерного массива, а использовать натацию вложенных множеств. Тогда пробем с пониманием будет меньше.
У меня нет проблемы с пониманием иерархического представления нескольких вью
Проблема будет у прикладника, который неправильно задаст индекс интересующего его вью из-за того, что этот индекс может трактоваться по-разному.
Ну да это в конце концов его проблемы. Ведь он может и номер строки в гриде неправильно задать.
Ладно, надо делать, там посмотрим, что из этого выйдет.
Нужно ли новый интерфейс добавлять — IViewContainer? Его должны реализовывать как ВГ, так и GridView.
Здравствуйте, Al-Ko, Вы писали:
AK>Проблема будет у прикладника, который неправильно задаст индекс интересующего его вью из-за того, что этот индекс может трактоваться по-разному.
Согласись, проблем с плоским списком у него будет намного больше.
AK>Ну да это в конце концов его проблемы. Ведь он может и номер строки в гриде неправильно задать.
Как говорится бывает на разные буквы авфафита. Даже на Ё.
AK>Ладно, надо делать, там посмотрим, что из этого выйдет.
Вот это верно!
AK>Нужно ли новый интерфейс добавлять — IViewContainer? Его должны реализовывать как ВГ, так и GridView.
Нет не нужно. Нужно использвать CollectionBase и делать на его основе типизированную коллекцию. Или использовать IList. Если мы переходим на второй фрэймворк, то IList<T>. Кстати, мы таки переходим? Вроде речь шла об этом, и о переходе на SVN...
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
VD>>Еще раз прошу не использовать натацию многомерного массива, а использовать натацию вложенных множеств. Тогда пробем с пониманием будет меньше. AK>У меня нет проблемы с пониманием иерархического представления нескольких вью AK>Проблема будет у прикладника, который неправильно задаст индекс интересующего его вью из-за того, что этот индекс может трактоваться по-разному.
Как прикладник могу сообщить, что на мой взгляд вложенные множества гораздо удобнее для понимания и программирования. В этом вопросе я полностью поддерживаю Влада.
Может, я действительно чего-то не понимаю
AK>>Нужно ли новый интерфейс добавлять — IViewContainer? Его должны реализовывать как ВГ, так и GridView. VD>Нет не нужно.
Ну я его хотел ввести для вспомогательных методов, типа Split, работа со сплиттерами и т.д.
VD>Нужно использвать CollectionBase и делать на его основе типизированную коллекцию. Или использовать IList. Если мы переходим на второй фрэймворк, то IList<T>. Кстати, мы таки переходим? Вроде речь шла об этом, и о переходе на SVN...
Так тут все от тебе зависеть. Я бы перешел и туда, и туда. Люблю новшества
Это я не подумал. Хотя если совместить вью и коллекцию в одном флаконе... но это не очень верное архитектурное решение. К тому же не так часто и много прийдется с этими вью возиться.
AK>Может, я действительно чего-то не понимаю
Да вроде все понял.
AK>Ну я его хотел ввести для вспомогательных методов, типа Split, работа со сплиттерами и т.д.
А зачем тогда IViewContainer? Это нужно прямо у вью и делать.
AK>Так тут все от тебе зависеть. Я бы перешел и туда, и туда. Люблю новшества
Ну, тогда ты все доведи до более менее нормального промежуточного состояния, отрапортуй мне и я переведу все сразу и на второй дотнет, и под свина.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AK>>Ну я его хотел ввести для вспомогательных методов, типа Split, работа со сплиттерами и т.д. VD>А зачем тогда IViewContainer? Это нужно прямо у вью и делать.
1) для правильной объектной декомпозиции. Потому что особенности View как контейнера других View являются отдельной, так сказать, темой для разговора. Точно так же, как его особенность осуществлять скроллинг или обработку ввода.
2) VirtualGrid тоже является контейнером View, но не является View. Самое лучшее — реализовать общий интерфейс IViewContainer.
В этот интерфейс будет вынесена свойством коллекция Views и (как ты подметил ) синтаксический сахар в виде методов типа Split, Merge и т.д. По-моему, все логично
VD>Ну, тогда ты все доведи до более менее нормального промежуточного состояния, отрапортуй мне и я переведу все сразу и на второй дотнет, и под свина.
k
я уже, кстати, пробовал его переводить под Express 2005. Проект компилируется и даже работает!
Здравствуйте, Al-Ko, Вы писали:
AK>В этот интерфейс будет вынесена свойством коллекция Views и (как ты подметил ) синтаксический сахар в виде методов типа Split, Merge и т.д. По-моему, все логично
Не логично. Не следует мешать функциональность коллекции и хранимых в ней типов. Это чревато проблемами. Я тут как-то допустил такую ошибку, и потом очень долго мучался. В итоге зарефакторил все и разделил коллекцию и хнанимые в ней итпы.
Коллекция должна содержать методы монипуляции со множествами (в ней хранящимися). Но она не должна по совместительству еще быть контейнером и т.п. Ее задачи хранить псписок.
AK>я уже, кстати, пробовал его переводить под Express 2005. Проект компилируется и даже работает!
А с чего бы ему не работать то? Это уж нужно очень сильно нашорудить...
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Не логично. Не следует мешать функциональность коллекции и хранимых в ней типов. Это чревато проблемами. Я тут как-то допустил такую ошибку, и потом очень долго мучался. В итоге зарефакторил все и разделил коллекцию и хнанимые в ней итпы.
Может ты не понял?
public abstract class VirtualGridBase:
System.ComponentModel.Component,
IVirtualGrid, IViewContainer
{
...
и
public class GridView: IGridView, IViewContainer
{
...
ведь у нас же коллекция сейчас выглядит так:
public class ViewCollection:IList
{
ArrayList _innerArray;
IVirtualGrid _owner;
public ViewCollection(IVirtualGrid owner)
{
_innerArray = new ArrayList();
_owner = owner;
}
......
а будет так:
public class ViewCollection:IList
{
ArrayList _innerArray;
IViewContainer _owner;
public ViewCollection(IViewContainer owner)
{
_innerArray = new ArrayList();
_owner = owner;
}
......
VD>Коллекция должна содержать методы монипуляции со множествами (в ней хранящимися). Но она не должна по совместительству еще быть контейнером и т.п. Ее задачи хранить псписок.
коллекцию мы не трогаем, а просто приводим вью и ВГ к одному интерфейсу как к сущности, управляющими вложенными вью.
Вообще, если ты помнишь, система сейчас такая:
ВГ содержит коллекцию Вью из элементов типа GridView. При добавлении нового Вью метод Add коллекции обращается к интерфейсу IViewManager. Этот интерфейс реализуется ПАЛ-контролом, который и создает физический Вью (Win32View). Этот физический вью сопоставляется с "виртуальным" GridView, который находится в коллекции.
А теперь, учитывая вложенность GridView, будет происходить все примерно также, но GridView, поскольку сам содержит вложенные вью, будет реализовывать интерфейс IViewContainer, а физический вью, равно как и ПАЛ-контрол, должен реализовывать IViewManager.
Таким образом, управление вью на виртуальном уровне осуществляется ВГ и GridView через интерфейс IViewContainer, а на физическом уровне им занимаются ПАЛ-контрол и зависимый от платформы вью через IViewManager
получается, GridView тоже нужно делать компонентом, чтобы сериализация в код нормально проходила?
Тогда в коде формы получается примерно такая картина:
Здравствуйте, Al-Ko, Вы писали:
AK>получается, GridView тоже нужно делать компонентом, чтобы сериализация в код нормально проходила?
Я кстати, могу сделать и сериализацию в одну строку, чисто по иерархии, и не делать вью компонентом, но тогда у GridViews дочерние Views будут содержаться не в коллекции, а в массиве. Ну и соответственно траблы, с этим связанные. Нужно тогда будет добавить в методы вью такие методы, как Remove и Add (именно вью, т.к. дочерней коллекции нет, есть только массив).
Но вариант с компонентами мне лично больше нравится.
Здравствуйте, Al-Ko, Вы писали:
AK>получается, GridView тоже нужно делать компонентом, чтобы сериализация в код нормально проходила?
Вовсе не обязательно. Достаточно создать тайп-конвертор возвращающий TypeDescriptor.
AK>Тогда в коде формы получается примерно такая картина:...
Несовсем. Для Вьюх отдельные переменны ненужны. Они могут создаваться прямо при добавлении, а их состояние можно передавать через параметры конструктора.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
AK>Здравствуйте, Al-Ko, Вы писали:
AK>>получается, GridView тоже нужно делать компонентом, чтобы сериализация в код нормально проходила?
AK>Я кстати, могу сделать и сериализацию в одну строку, чисто по иерархии, и не делать вью компонентом, но тогда у GridViews дочерние Views будут содержаться не в коллекции, а в массиве. Ну и соответственно траблы, с этим связанные. Нужно тогда будет добавить в методы вью такие методы, как Remove и Add (именно вью, т.к. дочерней коллекции нет, есть только массив).
AK>Но вариант с компонентами мне лично больше нравится.
статью... конкретно раздел "Сериализация простых классов". Там подробно написано, как сделать простые классы сериализуемыми в код. Никаких массивов или компонентов для этого ненужно.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
статью... конкретно раздел "Сериализация простых классов". Там подробно написано, как сделать простые классы сериализуемыми в код. Никаких массивов или компонентов для этого ненужно.
я ее прочел, когда она еще не была написана
VD>Вовсе не обязательно. Достаточно создать тайп-конвертор возвращающий TypeDescriptor.
усе ясно. Но как сериализовать вложенные коллекции?
Ведь сам код, генерируемый при сериализации, должен выглядеть так:
_simpleGrid.Views.AddRange(new GridView[]
{
new GridView(new GridView[]
{
new GridView(),
new GridView()
}),
new GridView(new GridView[]
{
new GridView(),
new GridView(),
new GridView()
})
});
Здесь создается у ВГ два дочерних Вью-контейнера, у первого из них создается два окна отображения грида, а у второго — три.
Я специально опустил все другие параметры конструктора GridView. Получается, у GridView для этого случая есть два конструктора:
один:
public GridView(GridView[] views)
{
_views.AddRange(views);
}
и второй пустой, без параметров.
В классе GridView, как и в классе ВГ имеется коллекция Views:
/// <summary>
/// Коллекция дочерних областей вывода грида на экран
/// </summary>
[Category ("GridView")]
[DesignerSerializationVisibility(
DesignerSerializationVisibility.Content)]
public ViewCollection Views
{
get
{
return _views;
}
}
И, наконец, выдержка из тайпконвертора для GridView:
Вот при таком раскладе и получается код сериализации, приведенный выше — я ничего другого не смог придумать.
И если ты в прикладном коде захотел создать какие-нибудь дочерние View, пишешь:
GridView myView = new GridView();
GridView anotherView = new GridView();
myGrid.Views.Views[0].Views[1].AddRange(myView, anotherView);
А вообще, если честно, когда я с этим связался, сдается мне, что эта идея с вложенными Вью очень наворочена и сложна. Теперь для каждого вью нужно проверять, если его коллекция Views пуста, то он работает как окно отображения, а если там есть элементы, то он работает как контейнер. Другая обработка отрисовки, другая работа со скроллингом, со вводом и т.д. Объем работы удваивается, а выигрыша немного. Когда оно все существовало в плоском виде, таких проблем не возникало.
Может подумаем, и еще чего-то придумаем? Например со строками, столбцами и объединением, но так, чтобы все вью находились в одной коллекции при ВГ?
Здравствуйте, Al-Ko, Вы писали:
AK>усе ясно. Но как сериализовать вложенные коллекции?
Так и сериализовать. Они будут передаваться в качестве параметров конструктора.
AK>Ведь сам код, генерируемый при сериализации, должен выглядеть так:
AK>
AK>_simpleGrid.Views.AddRange(new GridView[]
AK> {
AK> new GridView(new GridView[]
AK> {
AK> new GridView(),
AK> new GridView()
AK> }),
AK> new GridView(new GridView[]
AK> {
AK> new GridView(),
AK> new GridView(),
AK> new GridView()
AK> })
AK> });
AK>
Ну, что-то вроде...
AK>Здесь создается у ВГ два дочерних Вью-контейнера, у первого из них создается два окна отображения грида, а у второго — три.
AK>Я специально опустил все другие параметры конструктора GridView. Получается, у GridView для этого случая есть два конструктора:
AK>один: AK>
Их будет 32. Для всех сочетаний параметров (это кстати самое неприятное при использовании сериализации через InstanceDescriptor).
AK>В классе GridView, как и в классе ВГ имеется коллекция Views...
Ну, примерно... Я так и не монял что тебе не ясно?
AK>А вообще, если честно, когда я с этим связался, сдается мне, что эта идея с вложенными Вью очень наворочена и сложна. Теперь для каждого вью нужно проверять, если его коллекция Views пуста, то он работает как окно отображения, а если там есть элементы, то он работает как контейнер. Другая обработка отрисовки, другая работа со скроллингом, со вводом и т.д. Объем работы удваивается, а выигрыша немного. Когда оно все существовало в плоском виде, таких проблем не возникало.
Да ничего там не удваивается если грамотно провести декомпозицию и не валить все в одну кучу.
Ну, а что сложнее... Дык что же ты хочешь? Больше фич — выше сложность.
Короче, я тут сделал тестовую вресию с более менее прямым дизайном. Лежит тут: http://gzip.rsdn.ru/File/73/ViewTest.zip . Возьми ее за основу и все будет ОК.
AK>Может подумаем, и еще чего-то придумаем? Например со строками, столбцами и объединением, но так, чтобы все вью находились в одной коллекции при ВГ?
Не надо в одной. Вот это и будет неприемлемый наворон. Вот код сериализации вью с вложенностью:
this.userControl11.Views.AddRange(new ViewTest.View[] {
new ViewTest.View(),
new ViewTest.View(new ViewTest.View[] {
new ViewTest.View(),
new ViewTest.View(ViewTest.DocingType.Right)}),
Выглядит ясно и понятно. Никаких наворотов. Управляемая структура. Что еще надо?
Мы же уже обсуждали не раз. Плсокая структура выльется в куда большую сложность.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Короче, я тут сделал тестовую вресию с более менее прямым дизайном. Лежит тут: http://gzip.rsdn.ru/File/73/ViewTest.zip . Возьми ее за основу и все будет ОК.
хех, у меня все один к одному с твоей версией. Значит, правильной дорогой идем
VD>Выглядит ясно и понятно. Никаких наворотов. Управляемая структура. Что еще надо? VD>Мы же уже обсуждали не раз. Плсокая структура выльется в куда большую сложность.
думаешь? ну да ладно, жди результатов
Кстати, ты знаешь, у нас по ходу пьесы как-то выпадает класс Win32PalControl. Поскольку у нас GridView может рекурсивно содержать другие GridView, то его физическая репрезентация Win32View полностью заменяет функции Win32PalControl'а. В классе Win32PalControl содержатся: ссылки на интерфейсы IVGDrawContext и IVirtualGrid, а также методы создания и удаления дочерних контролов. Но то же самое имеется и в классе Win32View! Посему, предлагаю выкинуть Win32PalControl из проекта вообще и оставить систему: физический контрол — виртуальный GridView — ВГ — виртуальный DrawContext.
Здравствуйте, Al-Ko, Вы писали:
AK>Кстати, ты знаешь, у нас по ходу пьесы как-то выпадает класс Win32PalControl. Поскольку у нас GridView может рекурсивно содержать другие GridView, то его физическая репрезентация Win32View полностью заменяет функции Win32PalControl'а. В классе Win32PalControl содержатся: ссылки на интерфейсы IVGDrawContext и IVirtualGrid, а также методы создания и удаления дочерних контролов. Но то же самое имеется и в классе Win32View! Посему, предлагаю выкинуть Win32PalControl из проекта вообще и оставить систему: физический контрол — виртуальный GridView — ВГ — виртуальный DrawContext.
А на экран ты что будешь бросать? Как это будет выглядеть при смене платформы?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А на экран ты что будешь бросать?
Win32View VD>Как это будет выглядеть при смене платформы?
WhidbeyView, Win32View, LinuxView
Здравствуйте, VladD2, Вы писали: AK>>WhidbeyView, Win32View, LinuxView
VD>И в чем они хостится будут?
в чем сейчас PAL-контрол хостится, в том будут и они. Точно такая же система: сперва на форму бросаешь, например, Win32View. Потом задаешь ему грид и контекст отрисовки. Затем, при добавлении View в коллекцию грида, происходит добавление соответствующих Win32View в коллекцию Controls родительского физического вью.
Ведь и PAL-контрол и ПАЛ-вин32 View — это винформсовские контролы. До введения рекурсивных вью они отличались тем, что PAL-контрол мог содержать дочерние вью-контролы, а Win32View — нет. А теперь они будут выполнять одни и те же функции. Так зачем нам PAL-контрол?
Здравствуйте, Al-Ko, Вы писали:
AK>Здравствуйте, VladD2, Вы писали: AK>>>WhidbeyView, Win32View, LinuxView
VD>>И в чем они хостится будут?
AK>в чем сейчас PAL-контрол хостится, в том будут и они.
Сейчас вроде как все в ПАЛ-е хостится, а не ПАЛ хостится.
AK> Точно такая же система: сперва на форму бросаешь, например, Win32View.
Бросать View? А не слишком радикально?
- Вы бы могли полюбить радикала?
— Ради чего?
AK>Ведь и PAL-контрол и ПАЛ-вин32 View — это винформсовские контролы.
Это в этой реализации они контролы. А там могут быть чем угодно.
AK> До введения рекурсивных вью они отличались тем, что PAL-контрол мог содержать дочерние вью-контролы, а Win32View — нет. А теперь они будут выполнять одни и те же функции. Так зачем нам PAL-контрол?
Ну, гляди. Тебе виднее.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вопросы: как нам регулировать, по горизонтали или по вертикали распологаются вновь созданные вью? Как нам задавать, с какой стороны будут добавляться вью — справа или слева для горизонтального расположения, сверху или снизу для вертикального?
Может, ввести свойство, определяющее порядок добавления вью, принимающее значения RightToLeft, BottomToUp и т.д? Как установишь его в родительском вью, в таком порядке и будут добавляться дочерние вью. Будь-то пачками через AddRange, или по-одиночке, через Add.
А как насчет того, что у прикладного пользователя появится путаница с определением индексов каждого вью на двух предыдущих рисунках?
А что, вообще, мировой опыт говорит по этому поводу? У вас в ascDB-гриде было MultiView?
Здравствуйте, Al-Ko, Вы писали:
AK>Вопросы: как нам регулировать, по горизонтали или по вертикали распологаются вновь созданные вью? Как нам задавать, с какой стороны будут добавляться вью — справа или слева для горизонтального расположения, сверху или снизу для вертикального?
Можно сделать так как... Ввести свойство на подобии GrowStyle в TableLayoutPanel из второго фрэймворка. Оно указывает как будет вставляться следующий элемент. А так же добавить методы Insert и Add имеющие в качестве параметра перечисление говорящее о типе выравнивания вставляемого вью.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
AK>А как насчет того, что у прикладного пользователя появится путаница с определением индексов каждого вью на двух предыдущих рисунках?
Не думаю, что будут проблемы. Боюсь, что основной проблемой может стать, то что грид не будет готов в разумные строки и его забосят.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
мда, трудновато дается этот замысел со вложенными вью. Основная проблема — координация виртуальных GridView и реальных PalView. Тут еще все осложняется тем, что при десериализации кода коллекций вью такого вида:
this.userControl11.Views.AddRange(new ViewTest.View[] {
new ViewTest.View(),
new ViewTest.View(new ViewTest.View[] {
new ViewTest.View(),
new ViewTest.View(ViewTest.DocingType.Right)}),
сперва, естественно, создаются дети, а потом родители.
Раньше у нас был такой подход: сперва создавался хост — ПАЛ-контрол. Потом наследник ВГ, имеющий коллекцию вью. Когда в эту коллекцию добавлялись элементы, шло обращение к "фабрике дочерних контролов" ПАЛ-контрола через метод CreatePalView, и происходило создание этих контролов (ПАЛ-вью), которые затем добавлялись в коллекцию Controls дочерних контролов ПАЛ-контрола.
Но теперь это дело надо менять. У нас сейчас при десериализации первыми создаются GridView, которые ничего не знают, ни о наследнике ВГ, ни о ПАЛ-контроле.
Можно было как-то сделать, чтобы при создании GridView в его конструкторе уже создавался соответствующий ему ПАЛ-вью. Но кто его будет создавать? Доступа к ВГ га этом этапе у нас нет. Доступа к "фабрике дочерних контролов" ПАЛ-контрола поэтому тоже нет. У нас есть доступ к ней только в методе AddRange коллекции Views наследника ВГ. То есть на самом последнем этапе десериализации. Поэтому создание ПАЛ-вью в конструкторах GridView отпадает.
Получается, что только тогда, когда тип хозяина коллекции будет VirtualGridBase, а не GridView, в методе AddRange коллекции мы должны будем пройти по дереву Views от ВГ до низа и создать каждому вью его физическое воплощение?
Изложил все довольно запутанно, но надеюсь, что ты понял суть проблемы...
Здравствуйте, Al-Ko, Вы писали:
AK>Изложил все довольно запутанно, но надеюсь, что ты понял суть проблемы...
Не очень понял, понял ил я все правильно... но похоже нужно просто создавать все эти физические контролы только при окончании инициализации. Ввести некую замарозку и размарозку лайаута. Ну, и воспольозваться интерфейсом ISupportInitialize.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Короче, я тут сделал тестовую вресию с более менее прямым дизайном. Лежит тут: http://gzip.rsdn.ru/File/73/ViewTest.zip . Возьми ее за основу и все будет ОК.
извини за молчание, щас буду оправдываться
дело в том, что я две недели потратил на то, чтобы заставить работать твой тест в судии 2003 (причем безуспешно). Все компилируется, все сериализуется в код, но на стадии добавления одного вью в другой в дизайнере выскакивает какое-то внутреннее исключение в редакторе коллекций.
Я взял проект с нуля, убрал оттуда всю отрисовку, оставив только Win32View, VirtualGridBase, SimpleGrid, GridView и форму. И в старой студии постоянно при добавлении "внучатых" вью идет это исключение. Я могу передать call stack, но там одни внутренние вызовы — это видно при отладке из другой студии.
Преобразовал этот проект новой студией, открыл — в дизайнере все ОК. Если хочешь, переделай свой ViewTest для старой студии и посмотри. У меня в ней сериализация рекурсивных вложенных коллекций глючит в дизайнере.
Но самое страшное не это. Даже в экспрессе в твоем примере, если сделать вложенность трех-четырех "поколений" вью, начинаются глюки — либо не сразу происходит сериализация, либо она вообще не происходит. Ты можешь это проверить?
Здравствуйте, Al-Ko, Вы писали:
AK>дело в том, что я две недели потратил на то, чтобы заставить работать твой тест в судии 2003 (причем безуспешно). Все компилируется, все сериализуется в код, но на стадии добавления одного вью в другой в дизайнере выскакивает какое-то внутреннее исключение в редакторе коллекций.
Ёлы-палы. Сказал бы мне, я помог бы.
AK>Но самое страшное не это. Даже в экспрессе в твоем примере, если сделать вложенность трех-четырех "поколений" вью, начинаются глюки — либо не сразу происходит сериализация, либо она вообще не происходит. Ты можешь это проверить?
Код в СВН?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
— приведенная схема из твоего тестового проекта глючит в третей студии. Возникает внутреннее исключение о попытке обращения к неинициализированному объекту.
— при значительной вложенности View тестовый проект начинает глючить и в пятой студии.
Это у меня на компьютере. Можешь ли ты проверить это у себя?
В принципе для единообразия можно было бы.
Ты говоришь про Д, который в твоем и этом примере Ж.
) синтаксический сахар в виде методов типа Split, Merge и т.д. По-моему, все логично 
