Всем привет. Только не отправляйте сразу в поиск - там уже был.
Встала проблема при организации отдельного потока в приложении Windows Forms. Я просмотрел все что на форуме сть, все пользуются Invoke и BeginInvoke, сам с потоками только в консольных приложениях работал через Thread, и поэтому особых проблем раньше не было.

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

У тя там какая-то странная рекурсивность...
П.С. Что за гугл к топику прилип???? Он меня бесит    Уберите!!     

Это сообщение отредактировал(а) archeg - 20.10.2007, 14:42

Да я вообще не пойму замысла savage..

Что делает этот пример? Ну нажали кнопку, и что? Все происходит в одном потоке, второго нет. Так зачем Invoke? Это раз.

Во-вторых, допустим нажали кнопку и делегат сработал. Зашли в setToText()
BeginInvoke породил новый поток и текстбокс нуждается в Invoke. Вызвали. И дальше - все, тушите свет. 
это жесть!   
конечно бесконечная рекурсия с тем же делегатом, который вызывает BeginInvoke на самого себя... Короче - непонятно что хотел автор.


никто так не делает. Ты сделал делегат для обновления текстбокса? Ну так и обнови его. Зачем снова BeginInvoke вызывать?

Это новый участник форума! Ты ответь ему, чтоб не постился больше. Или модераторов попроси забанить за оффтоп его!!
 

мда. Похоже скоро винград станет гаджетом гугл. Все к этому идет  

archeg, спасибо!

tol05, я понимаю что это выглядит как сборная солянка   но это только из-за того что я еще толком не могу въехать как(к чему и почему) использовать invoke.
Пример такой выбрал потому что для меня то по сути не важно что там делается обновляется текстовое значение текст бокса или делаются какие то вычисления. Решил просто попробовать сделать что то элементарное, по типу таймера, для практики работы взаимодействия потоков и контролов формы.
Я под консоль делал на Thread`ах, там небыло таких проблем, проще как то было. А сейчас тонкостей всяких с формами еще не знаю. Вот и копаюсь.

А есть альтернативный способ? Только не таймер.

Ну и раз уж так. Не могли б вы объяснить, как же тогда грамотно организовать работу дополнительного потока, чтоб он мог изменять контролы на форме? Хотяб даже на моем простом примере.

Не въехал, как нет другого потока? Это ж АРМ  


Я не понимаю, почему люди так не любят таймеры? )

Да и вообще я против вызовов самого себя(я про метод setToText   )  в таком примере - только путаешься   

Я так понимаю эт просто пример) вряд ли кто-то так в коде будет писать....


эххх (

Это сообщение отредактировал(а) archeg - 20.10.2007, 18:20

savage, ок. Когда-то несколько топиков было на эту тему, но пока их найдешь... Проще еще раз написать... Итак:

Немного теории:
   Вин-формс контрол позволяет с собой работать только в том потоке, где он был создан. Т.е. в основном потоке программы (помеченном STAThread). Если нужно из другого потока обратиться к контролу - используется технология Invoke (о том, какие потоки часто требуют этого - ниже напишу). Если обращение к контролу идет из того же потока - Invoke не требуется.
   Как работает Invoke? Просто. Каждый поток имеет очередь сообщений. Контрол, к примеру, создан в потоке А. Вызвовом Invoke() из потока B мы посылаем сообщение потоку А (типа "а ну-ка вызови нам метод TextBox.Refresh()" ). 
   Посланное сообщение попадает в очерь потока А, а мы продолжаем работу в потоке B дальше (если вызывали BeginInvoke) или сидим в своем потоке B и ждем результатов (если вызывали Invoke). 
   Поток А отработал свою текущую задачу (через полчаса  ) и полез к себе в очередь сообщений смотреть, нет ли новых задач. Увидел наше сообщение и начал отрабатывать его. Поэтому вызов Invoke не всегда приводит к немедленному действию, можно достаточно долго ждать его результатов.
   Контрол имеет свойство Control.InvokeRequired - оно говорит, нужно ли использовать Invoke или нет (т.е. находишься ли ты в основном потоке или ты сейчас находишься во внешнем по отношению к контролу потоке). Это свойство - для удобства. Я им никогда не пользуюсь потому что всегда сам знаю "Required" ли контрол Invoke или нет  Просто самой архитектурой программы это обеспечиваю.
   Какие могут быть "другие потоки" - это рабочие потоки Thread, потоки пула потоков, потоки АРМ (Asynchronous Programming Model - те же потоки пула, на самом деле), потоки ввода/вывода. Ну и все, по-моему (BackGroungWorker я в расчет не беру - не люблю его... К нему, ИМХО, привыкнешь - вообще с потоками работать разучишься  )

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



Я имел в виду, что в программе не используются никакие другие потоки, кроме основного. Ну а то, что АРМ автор сам создает через BeginInvoke (хотя мог бы Invoke - и не было бы тогда АРМ   ) - это ж его выбор... ситуация этого не требовала...
Я это имел в виду.

Это сообщение отредактировал(а) tol05 - 20.10.2007, 18:49

tol05, благодарю за развернутый ответ! многое прояснилось! Спасибо большое