В конструкторе для окна WPF, что должно идти до InitializeComponent () и что после?

В общем, я инициализировал свойстваWindow сам передInitializeComponent() и настройка элементов управления, содержащихся в последующем. Однако я не был настолько последовательным, и я действительно не заметил проблемы с заказом. Так:

Am I (potentially) doing something horrible? In particular, are there any issues with setting properties of child controls before InitializeComponent()? What is good style in this regard?

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

public Foo Foo {get; protected set}
public FooWindow (Foo foo)
{
    Foo = foo;
    this.Closing += FooWindow_Closing;
    Foo.Frobbed += Foo_Frobbed;

    InitializeComponent();

    this.DataContext = this;
    this.Title = Foo.Name() + " Window";

    FooListView.ItemSource = Foo.CalculateList();

    FocusManager.SetFocusedElement(this, FooListView);
}

Это правильно? Должен ли я просто делать MVVM и не иметь ничего в моемWindow конструктор?

Ответы на вопрос(3)

что не требует визуального дерева, прежде чем позвонитьInitializeComponent().

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

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

 18 июл. 2012 г., 05:49
Да, это может быть проблемой.
 seeker18 июл. 2012 г., 04:18
Это действительно проблема? Я имею в виду, что пользователь не может видеть элемент управления, пока мы не вызовемWindow.Show(), что не произойдет, пока конструктор полностью не закроется. Я полагаю, это может быть больше проблемой дляUserControlНо даже в этом случае объект должен быть полностью построен к моменту его назначения.
Решение Вопроса

вы рискуете случайно перезаписать свойства объектами, которые были установлены в XAML, или использовать неинициализированный объект. Обычно выделение кода имеет более высокий приоритет, чем XAML, поэтому я бы оставил InitializeComponents (иначе, анализировать и загрузить XAML) наверху.

 02 сент. 2016 г., 17:48
Важно отметить, что при использовании MVVM, DataContext должен быть установленbefore вызов InitializeComponent () или ваши привязки ViewModel не будут установлены должным образом. InitializeComponent () вызывает все получатели привязки вашего свойства, поэтому, если он вызывается первым, ваши привязки не получат правильных значений, пока NotifyPropertyChanged снова не будет вызван для каждого из ваших свойств. Этот же принцип применим к любой другой логике инициализации, которая может повлиять на инициализацию вашего xaml.

Am I (potentially) doing something horrible? In particular, are there any issues with setting properties of child controls before InitializeComponent()?

Скорее всего, ваши дочерние элементы управления не будут доступны вам в коде до тех пор, пока вы не вызовете InitializeComponents. Как правило, это было бы плохо.

What is good style in this regard?

Это будет делом вкуса, но в целом я бы порекомендовал, чтобы, если вы собираетесь воспользоваться преимуществом разделения, которое дает вам XAML, я бы сделал это настолько далеко, насколько вы можете. Если вы делаете то, что логически связано с пользовательским интерфейсом, попробуйте сделать это в XAML. Это не столько вещь MVVM, сколько отделение презентации от логики. Большая часть того, что у вас есть в вашем примере кода, может быть сделано декларативно, даже если только через ValueConverters.

Например, если Foo был DependencyProperty, то вы также можете присоединить его в XAML и добавить обратные вызовы как часть обратного вызова ValueChanged. Опять же, это не MVVM, но оно довольно фундаментально для WPF.

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

Надеюсь, это поможет,

 seeker18 июл. 2012 г., 04:26
Я начинаю верить первой части, но это не проблема (как упомянуто вthis question) из OnLoaded вызывается несколько раз?
 seeker20 июл. 2012 г., 00:01
Спасибо за ваш информативный ответ. (Извините, я могу принять только один ответ, а другой пришел первым.)
 18 июл. 2012 г., 23:45
OnLoaded будет вызываться всякий раз, когда загружается ваш элемент управления, что является подходящим временем для перехвата событий и тому подобного. Вы также захотите отцепить их в OnUnloaded. Если это окно, то на самом деле вы никогда не должны видеть, что OnLoaded вызывается несколько раз, но с элементами управления это, как правило, следует соблюдать осторожность (связанный вопрос относится к страницам, которые часто загружаются / выгружаются).

Ваш ответ на вопрос