Czy napewno muszę korzystac z Invoke

0

Witam!

W większości tematów dotyczących wątków na tym forum można przeczytać, że jeżeli odwołujemy się do kontrolek z innego wątku niż ten, który ją utworzył należy użyć funkcji Invoke.
Zastanawiam się czy aby na pewno jest to konieczne.

 void Run()
        {
            for (int i = 0; i < 10000; i++)
            {
                labelTest.Text = String.Format("Run {0}", i);
                //Thread.Sleep(1000);
                //this.Invoke(this.m_DelegateAddString, new object[] { String.Format("Run {0}", i) });
            }

        }

        private void buttonStart_Click(object sender, EventArgs e)
        {
            //m_DelegateAddString = new DelegateAddString(this.AddString);
            Thread t = new Thread(Run);
            t.Start();
        }

Tworzę sobie wątek i zmieniam w nim pole Text kontrolki labelTest i wszystko działa poprawnie. Probowałem na wiele sposób doprowadzić do zawieszenia aplikacji w podobny sposób ale mi się nie udało.

0

Bo to bardzo szczegolny przypadek .... ale wyobraz sobie:

w tym samym czasie

  1. watek glowny przemalowywuje kontrolke (refresh)
  2. zmieniasz jej wartosc

i juz masz wyjatek ....

delegaty sa upierdliwe (a nawet bardzo !!!! kod troche traci na czytelnosci) aczkolwiek idea i kierunek sluszny :) (jest to ulepszane)

0
rattlezz napisał(a)

Witam!

W większości tematów dotyczących wątków na tym forum można przeczytać, że jeżeli odwołujemy się do kontrolek z innego wątku niż ten, który ją utworzył należy użyć funkcji Invoke.
Zastanawiam się czy aby na pewno jest to konieczne.

Tworzę sobie wątek i zmieniam w nim pole Text kontrolki labelTest i wszystko działa poprawnie. Probowałem na wiele sposób doprowadzić do zawieszenia aplikacji w podobny sposób ale mi się nie udało.

na jakiej wersji .NET to uruchamiasz (poniżej 2.0) ?

0

Pytam bo z tego co pamiętam to z komponentami swing javy w nowszych wersjach nie było takiego problemu. Może i tutaj coś się zmieniło, ... :D. Poza tym naprawdę staram się doprowadzic do zwiechy, ale nie mogę.

casual coder napisał(a)

na jakiej wersji .NET to uruchamiasz (poniżej 2.0) ?

</quote>

wersja 2.0

0

jak właściwość formularza CheckForIllegalCrossThreadCalls masz na true i nie sypie Ci wyjątkami to zapiszę się do partii kobiet...

0

Dzięki za odpowiedź.

casual coder napisał(a)

jak właściwość formularza CheckForIllegalCrossThreadCalls masz na true i nie sypie Ci wyjątkami to zapiszę się do partii kobiet...

CheckForIllegalCrossThreadCalls miałem ustawione na false. Zmieniłem na true i nareszcie zaczęło rzucać wyjątkami. To normalne że miałem ustawione na false. ? (Używam vs2005).

Zastanawia mnie teraz co się działo wcześniej. Dlaczego żadnej zwiechy, ani niepokojącego zachowania.

0

Zastanawia mnie teraz co się działo wcześniej. Dlaczego żadnej zwiechy, ani niepokojącego zachowania.

W dokumentacji jest napisane że zawieszenie programu nastąpi jeżeli kontrolka przejdzie w stan nieustalony. Poza tym musiałbyś w trakcie dostępu do kontrolki próbować z drugiego procesu także ją modyfikować. Ogólnie jest to rzecz którą NALEŻY zmienić a nie trzeba. Podczas uruchamianiu wersji release nie powinno być problemów.

UWAGA!!
Problemem może być także fakt żę nie każdy updejt z procesu innego niż proces który utworzył kontrolkę faktycznie spowoduje odświeżenie wartości!!!
Nie wiem czy jest to gdzies udokumentowane ale mi sie udało ;]

1 użytkowników online, w tym zalogowanych: 0, gości: 1