Здравствуйте, 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 тоже переименовывать?

В принципе для единообразия можно было бы.