При this.IsMdiContainer = False коллекция MdiChildren главной формы "уничтожается", следовательно и все child-формы.

Так что child форм просто нет.

P.S. Не советую так шутить в своих приложениях :-)

>А не подскажите как компонент, который находится в родительской форме, использовать в дочерней. Я думю, что можно использовать один объект sqlconnection на все приложение...

В приложениях MDI из Mdichild добраться до "главного окна" можна через ParentForm.

Только для ADO.NET совсем не критично несколько Connection.
Создавайте его там где надо. Открывайте соединение с базой данных как можно позже закрывайте как можно раньше.

>Только для ADO.NET совсем не критично несколько Connection.

Неправильно выразился. Для ADO.NET нет необходимости, и нет аналога Delphiского DataModule. Создавать экземпляр класс Connection можно в любом месте, где угодно и столько раз сколько нужно при этом производительность достаточно высока.


Думаю вам следует поближе познакомиться с технологией ADO.NET и вы поймете почему это все и как.

>Ну а с точки зрения удобства... если форм много, а соединение изменилось...

Ну меняется строка соединения, больше ничего.

>И еще - правильно ли я понял - sqlconnection`ов, dataadapter`ов должно быть много... а dataset`ов - один на каждую форму???

Всего по возможности должно быть мало :-). А dataSet вообще может быть один.
На самом деле очень распространненая практика, когда все функции работы с данными выносятся в отдельный модуль. Конечно мастера в Visual Studio .NET такое делать не могут. Вот и получается в основном что на каждой форме есть и несколько DataAdapter и Connection, а также DataSet.

Не знаю как остальные, но я лично никогда не оставляю соединение открытым (Open). Когда приходит необходимость обработки данных - просто создаю экземпляр класса Connection - открываю со своей строкой подключенияя- произвожу необходимые действия, и сразу же его закрываю. При этом руководствуюсь лозунгом: "Позже открыл - раньше закрыл". Поэтому и надобности в единном Connection нет, единственное(но необязательно) строка подключение - должна быть одна и быть общедоступной.

Я думаю все таки вам следует почитать что нибудь про "философию" ADO.NET и многие вещи тогда станут понятны.

Что главное- так это ADO и ADO.NET совершенно разные вещи, и техника работы с ADO не подходит (да и в основном не реализована) в ADO.NET.

>если да, то получается, что смысла в событиях почти нет - я всегда должен их инициировать явно? В вышеуказанном случае - писать свою обработку изменения значения this.IsMdiContainer в которой пробегаться по всем чилдам и закрывать их. Но мне всегда казалось, что события для того и нужны, чтобы обрабатывать вот такие случаи и освободить меня от этой рутинной работы.

Что то я не понимаю в чем проблема. Мне кажется большинство ситуаций надо предотвращать а не отлавливать. Здесь вывод напрашивается один это свойство не используется для корректного закрытия child-окон.

Ну что то еще найдете пишите, интересно.

Бред конечно но вполне возможно в следующей версии FrameWork будет срабатывать Closing у child-from в этой ситуации.

>А можно ли сделать так: создать экземпляр класса Connection в главной форме, а открывать и закрывать его уже по мере надобности в остальных.
Я не могу понять как прописывать этот экземпляр в компонентах на других формах. Например, я объявляю этот Connection в классе главной формы Form1. Указываю в обработчике события этой формы Load строку соединения с БД. Открываю другую форму на которой находится DataAdapter. Ему в качестве параметра надо указать экземпляр класса Connection. Но в визуальном редакторе его свойств видно только Connection`ы, котрые находятся на форме DataAdaptera.
У меня книга по программированию БД на VB.Net. Там автор пишет, что мол объявляем один коннекшн, создаем его и пользуем во все программе.


Измените "видимость" у своего Connection с private, например на internal (видимость на сборку). Объект Connection будет доступен из кода.

Теперь design. Очень много пошло вопросов по этой теме. Опишу один из способов как делается один Connection на все приложение. При этом все что касается доступа к БД тоже будет находиться в одном месте.

1) Создаете Component назовем его например DataManager.
2) На этот component "накидываем" DataAdapterы, Connection. При этом полностью используются различные мастера по генерации процедуры, SQL запросов и т.д.
3) В главной формы создаем объект нашего DataManager, устанавливаем его видимость, например в internal.
4) Нигде больше не создаем экземпляров класса DataAdapter а используем из нашего компонента DataManager.
5) В нашем компоненте можем создать различные процедуры. Из названия станет понятно их назначение.

FillMyDataSet(DataSet ds);
UpdateMyDataSet(DataSet ds);

6) Получаем аналог DataModule в Delphi. К которому мы можем обратиться в любой момент через главную форму и передать например свой DataSet для Fill, Update and etc.

Пример: