Ожидание долгого процесса и все еще обновление пользовательского интерфейса

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

Во-первых, почему вы хотите избежать DoEvents()?

Во-вторых, вы используете противоречивые термины.

ожидание == блокировка

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

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

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

    var dialog = new MessageBoxFormWithNoButtons("Please wait while I flip the jiggamawizzer");
    dialog.Shown += (_, __) =>
        {
            var task = Task.Factory.StartNew(() => WriteToDatabase(), TaskCreationOptions.LongRunning);
            while (!task.Wait(50))  // wait for 50 milliseconds (make shorter for smoother UI animation)
                Application.DoEvents(); // allow UI to look alive
            dialog.Close();
        }

    dialog.ShowDialog();

Модальное диалоговое окно запрещает пользователю что-либо делать, но любая анимация все равно будет работать, поскольку DoEvents() вызывается 20 раз в секунду (или чаще).

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

Вы не можете ждать в потоке пользовательского интерфейса.

Вместо этого добавьте обработчик события Exited. .

Я не знаю, упростит ли это вашу проблему, но мы используем элементы управления Essential Objects: http://www.essentialobjects.com/Products/EOWeb/ для управления нашими длительными процессами.

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

Нет необходимости в опросе/зацикливании Do-событий.

Вопрос в том, что пока ваш фоновый поток делает что-то, что вам не разрешено делать в форме.

Закрыть его, изменить поле редактирования? и т. д. Это делается через какой-то конечный автомат, который может быть таким простым, как вы отключаете кнопку, когда отключаете поток, а затем снова включаете ее в событии RunWorkerCompleted. Вы можете оставить buutom в покое и проверить логическое значение, называемое «занято», в его обработчике кликов.

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

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