[VB.NET] Chiamata a Sleep blocca l'intera applicazione

[eziogsv]

Domanda "da studio".

Sleep dovrebbe bloccare il Thread corrente... ma dello specifico form o dell' intera applicazione?

Mi spiego meglio. Ho una applicazione costituita di diversi Form.

Nel frmMain controllo tramite un evento Timer se è premuto il tasto Control

If GetAsyncKeyState(Keys.ControlKey).........

in un altro Form se si verificano determinate condizioni inserisco un lungo intervallo di attesa

Sleep(10000)

prima di eseguire altro codice.

Ebbene, per tutti quei 10 secondi l' evento Timer di frmMain non funge!! Oltretutto è un System.Timers.Timer.

Ho sostituito Sleep(10000) con

LastTime = Now
Do
Application.DoEvents()
Loop Until (Now - LastTime).Seconds > 9

e tutto funge, ma rimane la domanda: Sleep blocca l' intera applicazione? Ogni singolo Form non "vive" come un thread a parte?

[MItaly]

Di default i vari form "vivono" tutti in un singolo thread, che gestisce il message loop dell'applicazione.

[eziogsv]

quindi teoricamente, avendo 5 o più form aperti contemporaneamente, ognuno che "ragiona" con le sue routines ed ognuno con molti Sleep(500), al fine della ottimizzazione del programma sarebbe meglio, ad esempio, sostituire gli Sleep(500) con

For x =1 to 5
Application.DoEvents
Sleep(100)
Next

al fine di evitare, che so, che 3 Sleep(500) eseguiti di seguito in 3 Form diversi blocchino l' applicazione per 1.5 secondi? O pensando così sono più realista del re?

[oregon]

Sì, così è molto meglio, dal punto di vista della "prontezza" dell'interfaccia ai cambiamenti ...

Ma valuta anche, a seconda del tipo di problema, l'adozione di più thread ...

[eziogsv]

Originariamente inviato da oregon
Sì, così è molto meglio, dal punto di vista della "prontezza" dell'interfaccia ai cambiamenti ...

Ma valuta anche, a seconda del tipo di problema, l'adozione di più thread ...

Si, uso a tal fine dei BackGroundWorkers.

Ma a questo punto mi sorge spontanea una domanda, e sul web non è che trovo risposte adeguate:

Application.DoEvents si riferisce solo al thread principale?

Cioè, ha senso o no inserire un Application.DoEvents in un BackGroundWorker?

E posso mettere tranquillamente in un thread separato uno Sleep(50000) (esempio assurdo) o è sempre megli un for...next con Sleep minori e DoEvents?

[oregon]

Un worker thread dovrebbe svolgere del lavoro (anche pesante), ma non gestire interfaccia grafica e quindi non avere necessità di gestire i "messaggi" di Windows (da cui non dovrebbe utilizzare la DoEvents).

[MItaly]

Originariamente inviato da eziogsv
Cioè, ha senso o no inserire un Application.DoEvents in un BackGroundWorker?

No, Application.DoEvents() esegue un nuovo message loop che smaltisce i messaggi accumulati nella coda del thread corrente. Se il thread corrente non ha interfaccia grafica, non ha messaggi da smaltire, per cui non ha senso la DoEvents().

E posso mettere tranquillamente in un thread separato uno Sleep(50000) (esempio assurdo) o è sempre megli un for...next con Sleep minori e DoEvents?

Meglio la Sleep(), a meno ovviamente che il thread della GUI non stia aspettando il worker thread per qualche motivo.