catch access violation
hi! the program (test.exe) that tc tests shows a message dialog "access violation at address 0x0030393.." meanwhile the tests continues, though it makes no sense to do this. a goo...
Forum Discussion
I've found that if I imagine my TestComplete scripts as a sort of "idiot" user, my test scripts are more robust.
For instance, in the case of your AV message dialog, TestComplete is continuing to execute whatever automated actions it's been instructed; if those actions are non-visual (i.e. not interacting with the GUI), then TC doesn't detect that anything is out of sorts because it's not "looking" at the screen.
If, however, your automation attempts to access the UI under test that lies beneath the message dialog in the Z-order, TC will then notice a problem in the form of an "unexpected window". TC provides several ways to handle error messages or other unexepected or "overlapping" windows. See the help topic "Handling Unexpected Windows" for more information.
TestComplete cannot by default assume that you want to stop your test run just because there is an exception thrown in your application; there are (admittedly unfavorable) cases where a TC developer might wish the script to continue running after an AV; perhaps to see how the application under test handles the AV.
You should probably create a set of Unexpected Window handling scripts for if your UI scripts encounter the message. It's likely that TC is trying to handle the unexpected AV message in its default, optimistic way, through timeouts, waiting for the window to go away, etc.
In any case, you might also examine the help topic "Tracing Exceptions, Crashes and Freezes in Tested Applications".
For instance, in the case of your AV message dialog, TestComplete is continuing to execute whatever automated actions it's been instructed; if those actions are non-visual (i.e. not interacting with the GUI), then TC doesn't detect that anything is out of sorts because it's not "looking" at the screen.
If, however, your automation attempts to access the UI under test that lies beneath the message dialog in the Z-order, TC will then notice a problem in the form of an "unexpected window". TC provides several ways to handle error messages or other unexepected or "overlapping" windows. See the help topic "Handling Unexpected Windows" for more information.
TestComplete cannot by default assume that you want to stop your test run just because there is an exception thrown in your application; there are (admittedly unfavorable) cases where a TC developer might wish the script to continue running after an AV; perhaps to see how the application under test handles the AV.
You should probably create a set of Unexpected Window handling scripts for if your UI scripts encounter the message. It's likely that TC is trying to handle the unexpected AV message in its default, optimistic way, through timeouts, waiting for the window to go away, etc.
In any case, you might also examine the help topic "Tracing Exceptions, Crashes and Freezes in Tested Applications".
