2011-07-15 15 views
7

Estoy intentando automatizar la GUI de una aplicación externa usando C# /. NET 4.0¿Determina si una aplicación está bloqueada/ocupada?

La aplicación que se está automatizando (AUT) es una aplicación VB6.

Al hacer una acción, o hacer clic en un botón, el AUT a veces pasa mucho tiempo esperando que el DB responda. Cuando la aplicación está esperando los resultados de la base de datos, la aplicación está inactiva (no registra mucho uso de CPU), pero está bloqueada (no puede hacer clic o interactuar con ella).

-Hasta ahora, he intentado mirar el puntero del mouse (reloj de arena) como indicador, pero a veces la aplicación está bloqueada pero el cursor es normal. Entonces esto no es confiable.

-He intentado mirar el proceso principal de AUT para TotalProcessorTime (esto mide si la aplicación está inactiva o OCUPADA), pero como he dicho, a veces la aplicación está inactiva, y todavía está bloqueada.

Así que me gustaría ponerle cinta adhesiva a la experiencia de la multitud de stackOverflow para ver si alguien ya sabe cómo manejar eso, y/o si tiene alguna idea sobre cómo lograr esto.

Gracias

EDIT:

He estado jugando alrededor, y acaba de descubrir algo.

Mientras que la AUT está bloqueada, no responde a la entrada del teclado o del mouse. Sin embargo, si envío mensajes WM_LBUTTONCLICK a la ventana, puedo confirmar que los mensajes se están procesando (y la IU cambia).

Así que supongo que están bloqueando a propósito la aplicación mientras hacen llamadas a la base de datos.

+0

¿Está la interfaz de usuario deshabilitada? ¿El bloqueo de subprocesos de la interfaz de usuario principal es un hilo de trabajo? ¿Ves la ventana fantasma si intentas interactuar con la aplicación? –

+0

No puede interactuar con la interfaz de usuario principal, sin embargo, no creo que el hilo de la interfaz de usuario principal sea bloqueante, ya que no ve ningún "efecto fantasma" cuando intenta interactuar con él. Simplemente no hace nada. Y todos los controles/UI todavía están "habilitados". – DanyO

+0

Consulte con Spy ++ si la ventana principal está desactivada o no. Si la cola de mensajes está siendo bombeada y no puede invocar acciones de UI, entonces algo en AUT debe estar deshabilitado, supongo. –

Respuesta

3

Puede comprobar si la interfaz de usuario de la aplicación que está respondiendo:

obtener la instancia de proceso para que la aplicación y comprobar su propiedad Responding. como:

//To get the process instance 
Process application = null; 
foreach (var process in Process.GetProcesses()) 
{ 
    if (process.ProcessName == "The Process Name") 
    { 
     application = process; 
     break; 
    } 
} 

//to check if the process UI is not responding 
if (application.Responding) 
{ 
    // 
} 

Editar: Puede modificar el tiempo de espera utilizado por application.Responding cheque this.

+0

Acabo de verificar, y en un punto donde la aplicación parece estar bloqueada, la aplicación. La respuesta devuelve TRUE, por lo que no podemos usar eso ... – DanyO

+0

@ DanyO: tal vez su proceso no tiene 'MainWindowHandle', [msdn] (http://msdn.microsoft.com/en-us/library/system.diagnostics.process.responding.aspx)' Si el proceso no tiene a MainWindowHandle, esta propiedad devuelve true., de lo contrario, esta propiedad debería funcionar como "AFAIK", ejemplo: check [this] (http://msdn.microsoft.com/en-us/library/aykwfbdh (v = vs.71) .aspx) –

+0

Acabo de verificar, y el proceso tiene un MainWindowHandle válido.De la documentación, ¿no se aplica "Procesar.Responder" solo a las aplicaciones que se consideran bloqueadas? La aplicación que estoy probando no está realmente colgada, solo está bloqueada hasta que recibe una respuesta de la base de datos. – DanyO

Cuestiones relacionadas