Здравствуйте, Al-Ko, Вы писали:

пишешь:

AK>

AK>GridView myView = new GridView();
AK>GridView anotherView = new GridView();
AK>myGrid.Views.Views[0].Views[1].AddRange(new GridView[] {myView, anotherView} );
AK>

наверное, надо так

Здравствуйте, 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>

AK>public GridView(GridView[] views)
AK>{
AK>_views.AddRange(views);
AK>}
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)}),

Выглядит ясно и понятно. Никаких наворотов. Управляемая структура. Что еще надо?

Мы же уже обсуждали не раз. Плсокая структура выльется в куда большую сложность.

Здравствуйте, VladD2, Вы писали:

VD>Короче, я тут сделал тестовую вресию с более менее прямым дизайном. Лежит тут: http://gzip.rsdn.ru/File/73/ViewTest.zip . Возьми ее за основу и все будет ОК.

хех, у меня все один к одному с твоей версией. Значит, правильной дорогой идем

VD>Выглядит ясно и понятно. Никаких наворотов. Управляемая структура. Что еще надо?
VD>Мы же уже обсуждали не раз. Плсокая структура выльется в куда большую сложность.
думаешь? ну да ладно, жди результатов

Здравствуйте, VladD2, Вы писали:

Кстати, ты знаешь, у нас по ходу пьесы как-то выпадает класс 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.

А на экран ты что будешь бросать? Как это будет выглядеть при смене платформы?

Здравствуйте, Al-Ko, Вы писали:

AK>думаешь? ну да ладно, жди результатов

Жду.

Здравствуйте, VladD2, Вы писали:

VD>А на экран ты что будешь бросать?
Win32View
VD>Как это будет выглядеть при смене платформы?
WhidbeyView, Win32View, LinuxView

Здравствуйте, Al-Ko, Вы писали:

AK>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-контрол?

Ну, гляди. Тебе виднее.

Здравствуйте, VladD2, Вы писали:

А теперь о расположении вновь созданных вью.

— допустим, мы имеем родительский вью, а в нем два вью — области отображения грида, распологающиеся рядом — слева и справа:

[0]
+--------+-------+
|        |       |
|        |       |
|        |       |
|[0].[0] |[0].[1]|
|        |       |
|        |       |
|        |       |
+--------+-------+

Вопросы: как нам регулировать, по горизонтали или по вертикали распологаются вновь созданные вью? Как нам задавать, с какой стороны будут добавляться вью — справа или слева для горизонтального расположения, сверху или снизу для вертикального?


как нам добавить этот вью снизу?:

[0]
+--------+-------+
|        |       |
|[0].[0] |[0].[1]|
|        |       |
+--------+-------+
|                |
|        ??      |
|                |
+--------+-------+

а этот сверху?:

[0]
+--------+-------+
|                |
|       ??       |
|                |
+--------+-------+
|                |
|[0].[0] |[0].[1]|
|                |
+--------+-------+

Может, ввести свойство, определяющее порядок добавления вью, принимающее значения RightToLeft, BottomToUp и т.д? Как установишь его в родительском вью, в таком порядке и будут добавляться дочерние вью. Будь-то пачками через AddRange, или по-одиночке, через Add.

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

А что, вообще, мировой опыт говорит по этому поводу? У вас в ascDB-гриде было MultiView?

Здравствуйте, Al-Ko, Вы писали:

AK>Вопросы: как нам регулировать, по горизонтали или по вертикали распологаются вновь созданные вью? Как нам задавать, с какой стороны будут добавляться вью — справа или слева для горизонтального расположения, сверху или снизу для вертикального?

Можно сделать так как... Ввести свойство на подобии GrowStyle в TableLayoutPanel из второго фрэймворка. Оно указывает как будет вставляться следующий элемент. А так же добавить методы Insert и Add имеющие в качестве параметра перечисление говорящее о типе выравнивания вставляемого вью.

Здравствуйте, Al-Ko, Вы писали:

AK>А как насчет того, что у прикладного пользователя появится путаница с определением индексов каждого вью на двух предыдущих рисунках?

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

Здравствуйте, VladD2, Вы писали:

мда, трудновато дается этот замысел со вложенными вью. Основная проблема — координация виртуальных 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.

Здравствуйте, VladD2, Вы писали:

VD>Короче, я тут сделал тестовую вресию с более менее прямым дизайном. Лежит тут: http://gzip.rsdn.ru/File/73/ViewTest.zip . Возьми ее за основу и все будет ОК.

извини за молчание, щас буду оправдываться

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

Я взял проект с нуля, убрал оттуда всю отрисовку, оставив только Win32View, VirtualGridBase, SimpleGrid, GridView и форму. И в старой студии постоянно при добавлении "внучатых" вью идет это исключение. Я могу передать call stack, но там одни внутренние вызовы — это видно при отладке из другой студии.

Преобразовал этот проект новой студией, открыл — в дизайнере все ОК. Если хочешь, переделай свой ViewTest для старой студии и посмотри. У меня в ней сериализация рекурсивных вложенных коллекций глючит в дизайнере.

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

Здравствуйте, Al-Ko, Вы писали:

AK>дело в том, что я две недели потратил на то, чтобы заставить работать твой тест в судии 2003 (причем безуспешно). Все компилируется, все сериализуется в код, но на стадии добавления одного вью в другой в дизайнере выскакивает какое-то внутреннее исключение в редакторе коллекций.

Ёлы-палы. Сказал бы мне, я помог бы.

AK>Но самое страшное не это. Даже в экспрессе в твоем примере, если сделать вложенность трех-четырех "поколений" вью, начинаются глюки — либо не сразу происходит сериализация, либо она вообще не происходит. Ты можешь это проверить?

Код в СВН?

Здравствуйте, VladD2, Вы писали:


VD>Код в СВН?

код в твоей ссылке в предыдущем сообщении. Это твой код.

Здравствуйте, VladD2, Вы писали:

еще раз повторю в чем проблемы:

— приведенная схема из твоего тестового проекта глючит в третей студии. Возникает внутреннее исключение о попытке обращения к неинициализированному объекту.

— при значительной вложенности View тестовый проект начинает глючить и в пятой студии.

Это у меня на компьютере. Можешь ли ты проверить это у себя?

Здравствуйте, Al-Ko, Вы писали:

AK>Здравствуйте, VladD2, Вы писали:


VD>>Код в СВН?

AK>код в твоей ссылке в предыдущем сообщении. Это твой код.

Ну, то есть отладить его под 2003-ей студией?