c# - varias - c backgroundworker

La ejecución de pruebas dentro de Backgroundworker finaliza de manera abrupta en elementos con muchos elementos secundarios

Question

Mi configuración general: hemos escrito un pequeño importador de Excel con una pequeña interfaz gráfica de usuario, que permite que los programadores no escriban y ejecuten pruebas de interfaz gráfica de comandos con comandos como "Botón.Hacer clic". El marco subyacente es TestStack.White. Después de importar el archivo de Excel y algunas otras interacciones con el usuario, la prueba comienza dentro de un System.ComponentModel.BackgroundWorker, que funciona bien, siempre y cuando no mire (o incluso interactúe con) elementos que contengan una gran cantidad de elementos secundarios.

Pero tan pronto como interactúo con un TestStack.White.UIItems.WindowItems.Window o un TestStack.White.UIItems.UIItemContainer que tiene muchos elementos, la ejecución de prueba acaba.

Con interactuar me refiero a todo, desde cosas simples como una comprobación no nula o una asignación a una variable local o cosas como pedir su número de niños. Algunos ejemplos que terminan la ejecución de prueba: 1)

if(theElement != null){ //everything after this line does not happen. The operator doesn''t seem to be overloaded
doStuff(); //it never reaches this point
}

2)

UIItemContainer pointOfInterest = theElement; //everything after this line does not happen

3)

System.Diagnostics.Debug.WriteLine("AmountOfElements: " + UIAnchor.Items.Count); //the output doesn''t come. everything after this line does not happen

En ventanas sin cientos de elementos, los tres ejemplos funcionan según lo previsto.

Por muchos elementos me refiero, por ejemplo, a una ventana que tiene un ScrollView dentro, que tiene una tabla con docenas o incluso cientos de entradas, donde cada entrada consta de 3-4 columnas con texto o una casilla de verificación o algo así.

Los Backgroundworkers RunWorkerCompleted y también el Disposed no son llamados. No obtengo ninguna excepción en absoluto, incluso con bloques de prueba / captura colocados a propósito, no obtengo nada de eso. El depurador llega a la línea que causa el problema y eso es todo. Nada viene después, incluso con 1h de espera.

En su lugar, solo obtengo un par de "El subproceso {ID de algún hexadecimal} ha salido con el código 259 (0x103)". En la ventana de salida de Visual Studio. Esto es de mi última ejecución de prueba:

The thread 0x830 has exited with code 259 (0x103).
The thread 0xfc0 has exited with code 259 (0x103).
The thread 0xc04 has exited with code 259 (0x103).

En la medida en que he entendido este mensaje, significa que el hilo sigue vivo. https://stackoverflow.com/a/22395548/1171328

Si entro en el depurador para verificar el contenido del elemento que causa el error, obtengo tiempos de espera en todos los elementos que vinieron después de los Elementos (la Lista con los elementos secundarios), incluidos los Elementos.

Además, el problema no es (¿o no debería serlo?) Que el hilo principal finalice, como sucedió en este hilo: tratando de pasar por el código de BackgroundWorker en la depuración, pero el programa finaliza inesperadamente porque la interfaz gráfica de usuario aún funciona bien.

¿Alguien tiene una idea de lo que podría estar pasando aquí o cómo solucionar este problema?

Así es como empiezo la aplicación:

Application app = TestStack.White.Application.Launch(pathToExeFile);
context.setApp(app); //context is a class with static variables to eas the access to all kind of stuff, so that i access it without having 20 parameters in every method (e.g. Button.Click())

Luego, el usuario establece qué ventana quiere probar (lo que podría o no ser una ventana modal, pero en las ventanas sin cientos de elementos funciona):

foreach (Window win in context.getApp().GetWindows()) {
System.Diagnostics.Debug.WriteLine("###SelectWindow: " + win.Name + " # " + win.PrimaryIdentification + " # " + win.Title);
if (win.Name.Equals(nameOfWindowToTest)) {
System.Diagnostics.Debug.WriteLine("###SelectWindow: gefunden");
context.UIAnchor = win;
System.Diagnostics.Debug.WriteLine("####SelectWindow: Anz Items: " + context.UIAnchor.Items.Count); //this gets called, but is the very last thing the thread does
return null; //does not happen
}
}

context.UIAnchor es el elemento mencionado anteriormente. Después, se llaman los métodos establecidos por el usuario (por ejemplo, Button.Click). Curiosamente, el contexto.UIAnchor = win y la salida de items.count funciona.

Actualización: Si cierro la aplicación que se va a probar, antes de cerrar el programa de prueba, obtengo una ElementNotAvaiableException. Así que el hilo no debería estar totalmente muerto.

Answer 1

¿Qué sucede si cambia al modo de manejo de excepciones heredado en el archivo app.config?

<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="1"/>
</runtime>
</configuration>

Answer 2

Siguiendo mi comentario anterior, creo que su BackgroundWorker lanza una excepción que no se muestra, tal vez debido a este error / característica .

La ejecución de este pequeño fragmento no muestra ninguna excepción no controlada hasta que marque "Lanzar" en el diálogo de depuración / excepción.

Public Class Form1
Private Sub BackgroundWorker1_DoWork(sender As Object, e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker1.DoWork
For I As Integer = 0 To 100
BackgroundWorker1.ReportProgress(I)
Threading.Thread.Sleep(25)
If I = 50 Then Throw (New NullReferenceException)
Next
End Sub
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
BackgroundWorker1.RunWorkerAsync()
End Sub
Private Sub BackgroundWorker1_ProgressChanged(sender As Object, e As System.ComponentModel.ProgressChangedEventArgs) Handles BackgroundWorker1.ProgressChanged
ProgressBar1.Value = e.ProgressPercentage
End Sub
Private Sub BackgroundWorker1_RunWorkerCompleted(sender As Object, e As System.ComponentModel.RunWorkerCompletedEventArgs) Handles BackgroundWorker1.RunWorkerCompleted
ProgressBar1.Value = 0
End Sub
End Class

(Lo siento por VB, debe aplicarse a cualquier CLR)

La muestra muestra (después de hacer clic en el botón) una Barra de progreso que se llena hasta en un 50% y luego se detiene, no se ejecuta BackgroundWorker, no se realiza ningún evento . Entrar en el Throw simplemente sale del método.

Edición: mi primera muestra no incluyó el evento RunWorkerCompleted, que ahora se está activando, por lo que esto podría no estar relacionado con su pregunta, perdón por el ruido.