Проверку OnPropertyChanged () называют на потоке UI в приложении MVVM WPF
Является ли это поведением поиска по умолчанию в Azure, и есть ли способ изменить его.
blockquote>К сожалению, в настоящее время нет способа настроить это поведение. В Поиске Azure мы используем выделитель сообщений Lucene. Этот маркер игнорирует совпадающие позиции терминов, поэтому вы видите, что все термины фразы подсвечиваются независимо.
Вы можете сослаться на аналогичную SO ветку .
Если вы хотите продвигать эту функцию, вы можете перейти на страницу обратной связи и проголосовать за нее.
4 ответа
WPF автоматически упорядочивает изменения свойства в потоке UI. Однако это не упорядочивает изменения набора, таким образом, я подозреваю Ваше добавление, что сообщение вызывает отказ.
можно упорядочить добавление вручную себя (см. пример ниже), или используйте что-то как эта техника , я вел блог о некоторое время назад.
Вручную маршалинг:
public void backgroundWorker_ReportProgress(object sender, ReportProgressArgs e)
{
Dispatcher.Invoke(new Action<string>(AddMessage), e.Message);
OnPropertyChanged("Messages");
}
private void AddMessage(string message)
{
Dispatcher.VerifyAccess();
Messages.Add(message);
}
У меня был похожий сценарий только на этой неделе (MVVM здесь также). У меня был отдельный класс, который делал свое дело, сообщая о состоянии обработчика событий. Обработчик события вызывался, как и ожидалось, и я мог видеть, что результаты возвращаются точно в срок с помощью Debug.WriteLine .
Но с WPF, что бы я ни делал, пользовательский интерфейс не будет обновляться до процесс был завершен. Как только процесс завершится, пользовательский интерфейс обновится, как и ожидалось. Это было так, как будто он получал PropertyChanged, но ждал завершения потока, прежде чем выполнять обновления всего интерфейса сразу.
(К моему ужасу, тот же код в Windows. Forms с DoEvents и .Refresh () работал как чудо.)
До сих пор я решил эту проблему, запустив процесс в своем собственном потоке:
//hook up event handler
myProcess.MyEvent += new EventHandler<MyEventArgs>(MyEventHandler);
//start it on a thread ...
ThreadStart threadStart = new ThreadStart(myProcess.Start);
Thread thread = new Thread(threadStart);
thread.Start();
, а затем в обработчике события:
private void MyEventHandler(object sender, MyEventArgs e) {
....
Application.Current.Dispatcher.Invoke(
DispatcherPriority.Send,
(DispatcherOperationCallback)(arg =>
{
//do UI updating here ...
}), null);
I ' Я не рекомендую этот код, так как я все еще пытаюсь понять модель потока WPF, как работает Dispatcher и почему в моем случае пользовательский интерфейс не будет обновляться до тех пор, пока не будет завершен процесс, даже если обработчик события будет вызван как ожидалось (по замыслу ?). Но до сих пор это работало для меня.
Я нашел эти две ссылки полезными:
http://www.nbdtech.com/blog/archive/2007/08/01/Passing-Wpf-Objects-Between- Темы-С-Source-Code.aspx
Я обрабатываю событие BackgroundWorker.ReportProgress вне моей ViewModel и передаю фактический экземпляр BackgroundWorker и ViewModel в мой класс, который определяет метод (ы) async .
Метод async затем вызывает bgWorker.ReportProgress и передает класс, который обертывает делегата как UserState (как объект ). Делегат, который я пишу как анонимный метод.
В обработчике событий я приводил его из объекта обратно к типу оболочки, а затем вызываю делегат внутри.
Все это означает, что я могу закодировать изменения пользовательского интерфейса непосредственно из кода, который выполняется асинхронно, но это просто обертка вокруг него.
Это объясняет более подробно:
http: //lukepuplett.blogspot. com / 2009/05 / update-ui-from-asynchronous-ops.html
Мне ДЕЙСТВИТЕЛЬНО нравится ответ Джереми: Диспетчеризация в Silverlight
Резюме:
Размещение диспетчера в ViewModel кажется неэлегантным
Создавая свойство Action
, установите для него просто запуск действия в конструкторе виртуальной машины - . При использовании виртуальной машины из V установите свойство Action для вызова диспетчера