Originariamente inviato da gibra
La butto lì (non ho mai provato), ma potrebbe essere benissimo che la creazione del'handle del programma che avvi non sia così immediata e veloce come nel caso di un banale programma come il Notepad o la calcolatrice.

Se metti la Sleep() PRIMA (e NON al posto) di WaitForInputIdle() cosa succede?

Ciao
Infatti è probabile che i programmi che avvio non siano così rapidi ad avviarsi come notepad o altro. Ed infatti il sistema non funziona anche con applicazioni come internet explorer o wordpad. La sleep() posso tranquillamente metterla prima della waitforinputidle() o metterla al suo posto e, se l'intervallo specificato nella sleep è sufficientemente ampio, il tutto funziona correttamente. Dirò di più. Con notepad, che funziona anche senza sleep(), posso tranquillamente fare a meno sia della sleep() che della waitforinputidle()!!! Insomma sembra che questa waitforinputidle() non sia bloccante come in realtà dovrebbe essere. La procedura ritorna sempre immediatamente true fregandosene altamente se l'applicazione che lancio sia pesante o meno.



Da msdn la funzione che cerchi di usare va bene se il processo utilizza un message loop e quindi effettivamente attende che finisca l'idle.. ma se non ce l'ha ritorna subito true..
E' vero che la funzione WaitForInputIdle funziona solo con processo che abbiano un message loop associato o in altre parole, con processi che abbiano una finestra grafica associata. Ma hai probabilmente letto male. Se il programma non ha un message loop la procedura ritorna immediatamente FALSE, mentre ne mio caso torna sempre immediatamente true. Per di più ho fatto una prova lanciando un eseguibile tramite console e infatti la procedura solleva un eccezione e l'errore visualizzato dice chiaramente che il processo non ha una interfaccia grafica associata. In quel caso la WaitForInputIdle ritorna "correttamente" false immediatamente.

Qui la cosa diventa misteriosa a mio parere.