Originariamente inviato da pietro09
:master: giusto appunto per capire. Lasciando perdere per il momento la soluzione del thread asincrono, non ho capito la faccenda dell'uso "vergognoso" di Application.DoEvents.
Il "vergognoso" proviene dal fatto che si tratta di un escamotage, di un espediente utilizzato per ottenere un effetto il cui mezzo ideale restano comunque i thread.

Inoltre, l'uso di Application.DoEvents può rendere meno performante (poiché forza l'elaborazione di tutti i messaggi in coda) il calcolo stesso, oltre al fatto che spesso si deve ricorrere a salti mortali (flag, disabilitazione di controlli, inibizione di metodi, ...) per evitare che l'utente possa invocare nuovamente il comando "pseudoasincrono" ("pseudo" perché non fa uso di thread) oppure chiudere addirittura l'applicazione.

L'uso di thread è senz'altro il metodo più consono, più corretto, più controllabile, meno "error prone", per ottenere lo scopo.

Siccome il vecchio VB6 non forniva meccanismi per supportare il multithreading, oltre al fatto che in certi casi si vorrebbe fare uso di DoEvents (anche se mi sfuggono i motivi), probabilmente è stato introdotto anche nel .NET Framework (ed esiste anche in altre librerie, ad esempio la VCL di Delphi); tuttavia, in genere lo si utilizza per implementare soluzioni che dovrebbero essere sviluppate con i thread, quindi meglio preferire questi ultimi, per questioni di performance, scalabilità e correttezza.

Ciao!