Originariamente inviato da alka
La spiegazione è molto semplice: l'avvio dell'elaborazione che modifica la proprietà Text del controllo Label avviene probabilmente alla generazione di un evento nell'applicazione, che corrisponde ad un determinato messaggio inserito nella coda dell'applicazione da Windows; fino a quando l'elaborazione non termina, l'applicazione non è in grado di gestire i messaggi successivi, tra cui molto probabilmente sono presenti quelli volti ad eseguire il "refresh" del controllo Label.

La stessa cosa vale anche per altri tipi di controlli, come la ProgressBar, ad esempio.

La soluzione al problema è quella di adoperare un thread esterno che esegua l'elaborazione, lasciando così il thread primario dell'applicazione libero di processare i messaggi in arrivo ed aggiornare i controlli visuali.

Ciao!
bhè si è sicuramente così, anche perchè l'ho sperimentato come dici tu su altri controlli.. cmq con la versione 2 del framework .net le cose si complicano ancora in quanto pur volendo "bindare" il controllo label da un thread separato, si presenta l'eccezione, che prima non veniva manco considerata e secondo me era molto meglio, la quale indica che l'accesso ad un controllo creato in un thread non uguale a quello in cui si cerca di popolare la label, non è consentito. Microsoft mette anche a disposizione un bel "CheckForIllegalCrossThreadCalls" che sinceramente non capisco a questo punto a cosa server.. insomma non capisco se è un problema di sicurezza che microsoft affronta in quanto se ne lava le mani facendo venire fuori questa eccezione in fase di debug ma cmq dando la possibiltà di accedere al thread separato in modo non sicuro..
Voglio dire:
O mi dici che bisogna accedere in thread-safe o no.. non si può aggirare qualcosa che hai inventato tu, è abbastanza paradossale non credi?