Tworzenie kontrole non-UI wątek

Question

mam coś w rodzaju modelu plug-in, w którym różne skomplikowane kontrole użytkownika są przechowywane w bibliotekach DLL i załadowane i instancję w czasie wykonywania przy użyciu

Activator.CreateInstanceFrom(dllpath, classname). 

Ponieważ jestem loading kilka z nich chciałem zrobić w tle, utrzymując mój interfejs w stanie gotowości, tworząc nowy wątek do ładowania. Kontrolki są następnie nadrzędne do formularza głównego i wyświetlane w razie potrzeby.

Wydaje się to działa dobrze - dopóki nie spróbuję ustawić żadnej właściwości w zagnieżdżonej kontrolce na jednej z tych kontrolek użytkownika, np. w procedurze obsługi zdarzenia przycisku, który zgłasza wyjątek z gwintem krzyża. Zdaje sobie sprawę, że mogłem tego uniknąć, sprawdzając InvokeRequired za każdym razem, gdy uzyskuję dostęp do właściwości, ale wolałbym nie martwić się o to podczas pisania kodu dla formantów użytkownika (zwłaszcza, że ​​są inni piszący te fragmenty kodu, którzy mogą nie zawsze pamiętam).

Moje pytanie brzmi: czy istnieje bezpieczny sposób wykonania tego, co próbuję, lub jak najlepiej załadować te elementy sterujące w tle? Czy jest to w zasadzie niemożliwe i czy muszę trzymać się głównego wątku do tworzenia kontroli?

Mam nadzieję, że informacje, które podałem, są wystarczające, aby moja sytuacja była jasna; jeśli nie, chętnie opracuję i dostarczę próbki kodu.

Answer 1

Dobrze jest załadować biblioteki DLL i utworzyć obiekty kontrolne w tle, ale kontrola musi zostać dodana do formularza w głównym wątku i wszystkich interakcji użytkownika, jak również każdej programowej zmiany właściwości kontrolnych (po tym, jak to się stało) stworzony) musi wystąpić w głównym wątku. Po prostu nie da się tego obejść, jak zapewne już wiesz. Teraz, chyba że ładowanie tych bibliotek DLL i tworzenie kontroli trwa wieki, nie widzę powodu, aby robić to w osobnych wątkach w tle.

Jeśli niektóre czynności wykonywane przez elementy sterujące blokują interfejs użytkownika i chcesz, aby wystąpiły w tle, jest to inna historia i lepiej przeanalizuj każde działanie indywidualnie i utwórz wyraźne metody komunikacji między wątkami interfejsu użytkownika. i wątki tła.

Próbując zrobić rodzajowe jeden odpowiadający wszystkim ramy, które działa tak samo w trybie wątku UI w trybie tła i po prostu sprawdza wyniki InvokeRequired czasami w gorzej wydajności (jak wszystkie wątki są zablokowane w Invoke) lub nawet w (niewykrytych) zakleszczeniach, gdy tylko aplikacja osiągnie rozsądną złożoność. Również robienie wszystkich aktualizacji asynchronizujących w BeginInvoke, bez uwzględnienia każdej metody osobno, może spowodować problemy z spójnością danych (tj. Kontrole mogą aktualizować się do stanów z powrotem w czasie z powodu odwrócenia kolejności wywołania między wątkami).

Answer 2

Przykładowy kod w numerze this answer zapewnia elegancki sposób obejścia tego problemu.

Kod cytat z tej odpowiedzi:

public void UpdateTestBox(string newText) 
{ 
    BeginInvoke((MethodInvoker) delegate { 
     tb_output.Text = newText; 
    });   
} 

... chociaż w przypadku co chcesz zadzwonić BeginInvoke na samych kontroli:

public void UpdateTestBox(string newText) 
{ 
    tb_output.BeginInvoke((MethodInvoker) delegate { 
     tb_output.Text = newText; 
    });   
} 

Answer 3

nie znając szczegóły mechanizmu InvokeRequired , Eksperymentowałem trochę i afaik, możesz ustawić większość właściwości w wątku, o ile nie został on parentowany (tj. Dodany do niektórych właściwości Control.Controls).

Powinieneś być w stanie przygotować kontrole, zapisać je na liście i dołączyć je do głównego interfejsu w metodzie Invoked.

---

Edytuj: Myślę, że nie ma znaczenia, który wątek utworzył kontrolę. Dlatego powinny obowiązywać normalne reguły, tzn. Można pracować tylko z formantami z głównego wątku systemu Windows. I myślę, że kryterium jest HandleCreated zamiast Parented. Dopóki to się nie wydarzy, dostaniesz odrobinę wytchnienia.