Quando si apportano modifiche ad un controllo visuale, viene invocata una funzione API che rende "invalido" l'aspetto del controllo: questo fa sì che Windows venga informato della necessità di ridisegnarlo, esigenza che viene servita da Windows inserendo un messaggio WM_PAINT nella coda dell'applicazione.

Se la modifica ad un membro che richiede l'aggiornamento del controllo è seguito da uno Sleep, il thread primario dell'applicazione - che si occupa di ricevere e gestire i messaggi in coda - viene messo in attesa e quindi non può che riprendere l'elaborazione solo quando il tempo di attessa è terminato, gestendo anche il messaggio in coda con cui si ottiene il ridisegno del controllo in esame.

Per aggirare l'ostacolo, eseguendo il metodo Repaint, si bypassa la coda dei messaggi e si esegue direttamente il disegno del controllo; tuttavia, se questo viene eseguito spesso, risulta inefficiente se si trova all'interno di un algoritmo.

In sostanza, il suo utilizzo dipende essenzialmente dallo scopo che si sta cercando di raggiungere.

In certi casi, può essere più indicato fare uso di thread secondari in questo contesto.

Ciao!