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

на выходе имею ошибку
а именно 

не обрабатывается по причине
"Недопустимая операция в нескольких потоках: попытка доступа к элементу управления 'Label1' не из того потока, в котором он был создан."
Надо мол использовать Invoke
А ВОТ КАК ? 
Я наскоком на справку понять не смог... 
прошу помощи коллективного разума 
Можно мне подсказать как на этом примере использовать эту безопасную многопоточность.



Это сообщение отредактировал(а) RUVATA - 22.2.2011, 15:26

Код внутри бресетов выполнится в основном потоке приложения. Имейте ввиду, что пока выполняется метод Invoke, ваш поток будет ждать отработки. Если вы не желаете, чтоб ваш поток ждал выполнения кода для окна, то используйте метод BeginInvoke.

Добавлено через 4 минуты и 39 секунд
Этот метод находится в классе Control, а это значит, что вы одинаково смело можете его вызывать у любого элемента окна.

Все равно, не понял... 
Я уже какие только примеры не пробовал, они даже синтаксическую проверку не проходят...
Можно попросить вас описать конструкцию, принципал... 

Вот допустим есть основной поток "Основной" в котором описана форма, с элементом управления "Кнопка"
Есть дополнительный поток "ВторПоток" 
Я хочу из "ВторПоток" изменять некое свойство объекта "Кнопка"
Такое действие само по себе не является потокобезопасным (бред Microsoft)
(в Swing Java такого геморроя нет, чтобы избежать взаимоблокировки или гонки там используются конструкции очереди потипо Try Cath с условием)
и дабы разрешить возможные конфликты совместного доступа, предлагается на выбор:
или сконструировать "ВторПоток" изначально специфическим BackgroundWorker , я еще не пробовал...
или использовать специальный метод вхождения в основной поток Invoke...
Но его суть я так и "нераскурил", какой делегат, кто он  , куда его, где собственно сам вызов и т.д.
Пример из справки просто тащит, т.к. он сам на этом-же исключении тормозит 

Это сообщение отредактировал(а) RUVATA - 24.2.2011, 09:14

делегат - это прокаченный указатель на функцию. Т.е. вы в Invoke() передаете указание "что делать". Invoke же ставит это "указание что делать" в оконную очередь на выполнение - winAPI функция SendMessage. Ф-я SendMessage является блокирующей и производит постановку сообщения в очередь Windows окна сообщений (стандартная оконнная очередь сообщений).

Далее, каждое окно (точнее процесс который создал окно) в системе Windows производит следующие нехитрые действия (чтобы окно не "зависло" и вообще как-то реагировало на юзера):

Это так называемая оконная процедура. Она работает в том же потоке (пока окно не будет уничтожено вызовом DestroyWindow()) что и создавалось окно. И это важное замечание.

Этот цикл производит ничто иное как прокачку (pumping) оконных сообщений непосредственно в процедуру (посредством вызова этой процедуры внутри функции DispatchMessage) обработки оконных сообщений окна, которая выглядит как-то так:


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

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


Такие дела.

Я, конечно, не особо уверен что обстоят дела именно так, но это моё мнение...

Это сообщение отредактировал(а) jonie - 24.2.2011, 10:10

Ну так и я так думал до определенной сотой попытки подпихнуть что ни будь типа

ну так нет-же в аргумент нужен объект типа System.Delegate
справка описывает его так 
"Представляет делегат — структуру данных, указывающую на статический метод или на экземпляр класса и метод экземпляра этого класса."
Ну во первых меня сильно долбит изобилие термина МЕТОД... мне-то нужно обратиться к СВОЙСТВУ... но не суть...
мне-бы банальный пример...
КАК ОБРАТИТЬСЯ ЧЕРЕЗ Invoke К СВОЙСТВУ ЭЛЕМЕНТА UI-ПОТОКА Label1.Text ИЗ ДОЧЕРНЕГО ПОТОКА

Методу Invoke надо в качестве аргумента передать метод. Если тебе нужно обратиться к свойству, то сделать это можно в передаваемом методе. То есть ты либо определяешь этот метод отдельно и передаешь на него ссылку
После чего делаешь так

Либо определяешь метод прямо в коде вызова


Это сообщение отредактировал(а) diadiavova - 24.2.2011, 11:11

diadiavova, Огромное спасибо, выручаешь уже не первый раз...
Я вот только сейчас "прозрел" на счет того что имеется  в виду как МЕТОД... 
Может я и не прав, но по моему это наводит путаницу... потому что это не МЕТОД (чей-же это метод UI-потока что ли? где базовый объект) в понимании ООП... это не что иное как ПРОЦЕДУРА вернее её экземпляр,
причем мне не понятно зачем этот наворот, неужели абстрактный  Sub () нельзя было включить в сам Invoke, а для извращений сделать отдельную перегрузку
и передавать собственно само обращение...
Просто лично меня МЕТОД вывел из рановесия... что за метод, чей, причем здесь метод вашпе... 
еще раз спасибо... 


Это сообщение отредактировал(а) RUVATA - 24.2.2011, 11:06

Сейчас в основных языках платформы очень много наворотов из ФЯ и их становится все больше. Не вижу в этом проблемы, по-моему это благо. Что касается терминологии, то она оопэшная только и всего. Работа с делегатами только поначалу кажется сложной, со временем разберешься  и станет трудно без них обходиться.  

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