Лучший способ получить доступ к элементу управления в другой форме в Windows Forms?

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

public bool ControlIsVisible
{
     get { return control.Visible; }
     set { control.Visible = value; }
}

Это создает надлежащее средство доступа к тому управлению, которое не представит полный набор управления свойств.

Это похоже на главного кандидата на разделение представления от модели данных. В этом случае Ваши предпочтения должны быть сохранены в отдельном классе, который запускает обновления события каждый раз, когда особое свойство изменяется (изучите INotifyPropertyChanged, если Ваши свойства являются дискретным набором, или в единственное событие, если они - больше свободной формы основанные на тексте ключи).

В Вашем структурном виде, Вы будете делать изменения на ваше усмотрение моделью, он тогда запустит событие. В Ваших других формах Вы подпишетесь на изменения, которыми Вы интересуетесь. В конечном счете обработчик, который Вы используете для подписки на изменения свойства, Вы используете это. InvokeRequired, чтобы видеть, находитесь ли Вы на правильном потоке для совершения вызова UI, в противном случае тогда используйте это. BeginInvoke для вызова требуемого метода обновить форму.

Необходимо только когда-либо получать доступ к контенту одного представления от другого при создании более сложных средств управления/модулей/компонентов. Иначе необходимо сделать это через стандартную архитектуру Образцового Контроллера Представления: необходимо соединить включенное состояние средств управления, о которых Вы заботитесь собирающийся некоторый предикат образцового уровня, который предоставляет правильную информацию.

, Например, если я хотел включить кнопку Save только, когда вся запрошенная информация вводилась, у меня будет метод предиката, который говорит, когда объекты модели, представляющие ту форму, находятся в состоянии, которое может быть сохранено. Тогда в контексте, где я выбираю, разрешить ли кнопку, я просто использовал бы результат того метода.

Это приводит к намного более чистому разделению бизнес-логики от логики представления, позволяя им обоим развиться более независимо — разрешение Вам создать один фронтенд с несколькими бэкендами или несколько фронтендов с единственным бэкендом легко.

также будет очень, намного легче записать модульные тесты и приемочные испытания для, потому что можно следовать" Доверие, Но Проверить " шаблон при этом:

1. можно записать один набор тестов, которые настраивают объекты модели различными способами и проверяют, что "savable" возвраты предиката соответствующий результат.

2. можно записать отдельный набор той проверки, подключена ли кнопка Save соответствующим способом с, "savable" предикат (независимо от того, что это для платформы в Какао на Mac OS X, которым это часто было бы посредством привязки).

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

Ваши дочерние формы должны действительно быть Формами? Они могли быть пользовательскими элементами управления вместо этого? Таким образом, они могли легко сгенерировать события для основной формы для обработки, и Вы могли лучше инкапсулировать их логику в единый класс (по крайней мере, логически, они уже после всех классов).

@Lars: Вы прямо здесь. Это было чем-то, что я сделал в мои очень начинающиеся дни и не должен был делать этого с тех пор, именно поэтому я сначала предложил генерировать событие, но мой другой метод действительно повредит любое подобие инкапсуляции.

@Rob: Да, звуки о праве:). 0/2 на этом...

@Lars, хороший запрос к передаче вокруг ссылок Формы, замеченных это также самостоятельно. Противный. Никогда не замечаемый их передал их к уровню BLL хотя! Это даже не имеет смысла! Это могло иметь право производительности, на которое серьезно повлияли? Если бы где-нибудь в BLL ссылка была сохранена, форма осталась бы в праве памяти?

у Вас есть мое сочувствие!;)

@Ed, РЕ Ваш комментарий о создании Форм UserControls. Dylan уже указал, что исходная форма инстанцирует многие дочерние формы, производя впечатление MDI-приложения (где я предполагаю, что пользователи могут хотеть закрыть различные Формы). Если бы я корректен в этом предположении, я думал бы, что они были бы содержащимися в полном порядке как формы. Конечно, откройтесь к исправлению хотя:)

Я соглашаюсь с использованием событий для этого. Так как я подозреваю, что Вы создаете MDI-приложение (так как Вы создаете много дочерних форм), и создает окна динамично и не мог бы знать, когда отказаться от подписки от событий, я рекомендую смотреть на Слабые Шаблоны События . Увы, это только доступно для платформы 3.0 и 3.5, но что-то подобное может быть реализовано довольно легкое со слабыми ссылками.

Однако, если Вы хотите найти управление в форме на основе ссылки формы, недостаточно просто посмотреть на набор управления формы. Начиная с каждого управления имеют свой собственный набор управления, необходимо будет рекурсивно вызвать через них всех для нахождения определенного управления. Можно сделать это с этими двумя методами (который может быть улучшен).

public static Control FindControl(Form form, string name)
{
    foreach (Control control in form.Controls)
    {
        Control result = FindControl(form, control, name);

        if (result != null)
            return result;
    }

    return null;
}

private static Control FindControl(Form form, Control control, string name)
{
    if (control.Name == name) {
        return control;
    }

    foreach (Control subControl in control.Controls)
    {
        Control result = FindControl(form, subControl, name);

        if (result != null)
            return result;
    }

    return null;
}

Я обработал бы это в родительской форме. Можно уведомить другую форму, что она должна изменить себя через событие.

После чтения дополнительных деталей я соглашаюсь с robcthegeek: сгенерируйте событие. Создайте пользовательский EventArgs и передайте необходимые параметры через него.

Первое не работает, конечно. Средства управления на форме являются частными, видимыми только для той формы дизайном.

, Чтобы обнародовать все это также не лучший способ.

, Если я хотел бы подвергнуть что-то внешнему миру (который также может означать другую форму), я делаю общественную собственность для нее.

public Boolean nameOfControlVisible
{
    get { return this.nameOfControl.Visible; }
    set { this.nameOfControl.Visible = value; }
}

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

otherForm.nameOfControlVisible = true;

можно также представить полные средства управления, но я думаю, что это слишком много, необходимо сделать видимым только свойства, которые Вы действительно хотите использовать снаружи текущей формы.

public ControlType nameOfControlP
{
    get { return this.nameOfControl; }
    set { this.nameOfControl = value; }
}

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

Этот вид связи между формами всегда раздражает меня. Я всегда пытаюсь сохранить UI максимально легким и независимый ..

я надеюсь, что это помогает. Возможно, Вы могли подробно остановиться на сценарии если нет?

Вы можете

1. Создать открытый метод с необходимым параметром в дочерней форме и вызвать его из родительской формы (с действительным cast)
2. Создание открытого свойства в дочерней форме и доступ к нему из родительской формы (с действительным приведением)
3. Создание другого конструктора в дочерней форме для установки параметров инициализации формы
4. Создание пользовательских событий и / или использование (статическое) классы

Лучшей практикой будет №4, если вы используете немодальные формы.