Обращение к элементу WinForms из потока, отличного от потока, в котором это элемент был создан

@bairog · Регистрация: 13.02.2009

Author24 — интернет-сервис помощи студентам

Пишу приложение, котором при загрузке формы в textbox на этой форме заносятся данные. Причем данных много и процесс занимает длительное время. Чтобы при запуске у пользователя не возникало ощущения, что форма "подвисла" сделал заполнение textbox в отдельном потоке. Реализовал через асинхронный делегат, в упрощенном виде можно представить программу так:

C#

using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Threading;
using System.Diagnostics;
 
namespace WindowsApplication2
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
 
        void TakesAWhile(int ms)
        {
            textBox1.AppendText("filling started");
            Thread.Sleep(ms);   //заполняем некоторое время
            textBox1.AppendText("filling completed");
            return;
        }
 
        public delegate void TakesAWhileDelegate(int ms);
 
 
        private void Form1_Load(object sender, EventArgs e)
        {
            TakesAWhileDelegate d1 = TakesAWhile;
            d1.BeginInvoke(3000, null, null);   //запустили поток заполнения textbox
            //дальше какие-то действия
        }
    }
}

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

Код

Control.CheckForIllegalCrossThreadCalls = false

в конструкторе формы.

Вопросы на повестке дня:
1)Насколько "хорошо" использование данного решения?
2)Есть ли другие потокобезопасные способы без "подвисания" формы (догадываюсь, что нет, т.к. textbox создан в главном потоке, но вдруг)?
3)Созданный BeginEnvoke дополнительный поток завершится после выполнения функции TakesAWhile или как?
И для чего тогда нужен метод EndEnvoke?

Заранее огромное спасибо.

@Mikant · 29.03.2010, 16:35

1) плохо. надо хотя бы так

C#

        private void SetTextSafe(string text) {
            Action chTxt = new Action(() => {
                this.Text = text;
            });
 
            if (InvokeRequired)
                this.BeginInvoke(chTxt);
            else chTxt();
        }

- это потокобезопасный метод. можно вызывать откуда угодно

2) явно подвисать сможет если мой BeginInvoke изменить на Invoke, а в теле chTxt поставить что-то типа Thread.Sleep(1000);

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

Добавлено через 4 минуты
или так:

C#

        private void SetTextSafe(string text) {
            if (InvokeRequired)
                this.BeginInvoke(new Action<string>((s) => {
                    SetText(s);
                }), text);
            else SetText(text);
        }
 
        private void SetText(string text) {
            this.Text = text;
        }

@Green · 29.03.2010, 17:30

bairog, используйте контрол BackgroundWorker. В нем уже все реализовано.
Подписываетесь на события: DoWork - длительный рабочий код, ProgressChanged - изменяем форму в соответсвии с процентом выполнения рабочего кода, RunWorkerCompleted - процесс закончен.

@Sergey2009 · 29.03.2010, 19:45

В GUI приложениях EndEnvoke не обязатателен. Лично я считаю, что лучше использовать отдельный поток (Thread) для длительных вычислений и выводить на форму по примеру Mikant. BackgroundWorker хорош, когда нужно вычислить что-либо в отдельном потоке и вывести это что-то в форму когда RunWorkerCompleted, более того, при старте BW возможно передать только один объект (при старте потока с использованием Thread можно передать несколько объектов). По поводу ProgressChanged - если честно то я так и не разобрался как, например, с его использованием производитьманипуляции с элементами формы, например , выводить текстовую информацию ... возможно он используется только для таких целей :-):
progressBar.Value = e.ProgressPercentage;

@Green 1923 / 428 / 41 Регистрация: 12.07.2007 Сообщений: 2,062
	29.03.2010, 17:30	3
	bairog, используйте контрол BackgroundWorker. В нем уже все реализовано. Подписываетесь на события: DoWork - длительный рабочий код, ProgressChanged - изменяем форму в соответсвии с процентом выполнения рабочего кода, RunWorkerCompleted - процесс закончен. 0

@Sergey2009 5 / 5 / 0 Регистрация: 01.02.2010 Сообщений: 98
	29.03.2010, 19:45	4
	В GUI приложениях EndEnvoke не обязатателен. Лично я считаю, что лучше использовать отдельный поток (Thread) для длительных вычислений и выводить на форму по примеру Mikant. BackgroundWorker хорош, когда нужно вычислить что-либо в отдельном потоке и вывести это что-то в форму когда RunWorkerCompleted, более того, при старте BW возможно передать только один объект (при старте потока с использованием Thread можно передать несколько объектов). По поводу ProgressChanged - если честно то я так и не разобрался как, например, с его использованием производитьманипуляции с элементами формы, например , выводить текстовую информацию ... возможно он используется только для таких целей :-): progressBar.Value = e.ProgressPercentage; 0

Опции темы