We are building a new experience for our SmartBear Community.
This site is now read-only. You can still browse and search as usual. Learn More
This site is now read-only. You can still browse and search as usual. Learn More
Forum Discussion
Solved
.net application plugin/support crashes during script playback
pseudo code:
Sys.Process("Infinity").WinFormsObject("frmCATFRAMS").someobject.click();
//after the control is clicked the application performs a CPU intensive task
Sys.Process("Infinity").WinFormsObject("frmCATFRAMS").someotherobject.click();
//this subsequent click now fails because the .Net support and extended object properties are failing
//the form name is now the generic: Sys.Process("Infinity").Window("WindowsForms10.Window.8.app.0.202c666", "INFINITY™ Version: 11.7.1.1", 1)
//restarting Test Complete or disabling all/then enabling all plugins will restore extended properties
Sys.Process("Infinity").WinFormsObject("frmCATFRAMS").someobject.click();
//after the control is clicked the application performs a CPU intensive task
Sys.Process("Infinity").WinFormsObject("frmCATFRAMS").someotherobject.click();
//this subsequent click now fails because the .Net support and extended object properties are failing
//the form name is now the generic: Sys.Process("Infinity").Window("WindowsForms10.Window.8.app.0.202c666", "INFINITY™ Version: 11.7.1.1", 1)
//restarting Test Complete or disabling all/then enabling all plugins will restore extended properties
- Tanya,
I was skeptical so I gave this a try.
Predictably this proposed solution had no impact on the issue I am experiencing.
If the .Find method times out during CPU intensive application processing extended properties are no longer available. I am still unable to work around this without setting the Auto-wait timeout to a value greater than the applications process time. From your code the "mainForm" in this scenario does exist, but is currently "Unresponsive" while processing....during that "Unresponsive" state I am performing a .Find on the form...
(mainForm.Find(prop,propVal,depth) )...the Find method appears to be waiting up until the auto-wait timeout and then causes the .Net plugin support to crash or become unavailable.
9 Replies
- Marsha_R
Champion Level 3
We went through a period where that happened to us a lot. I think it was when we were doing a lot of name mapping at once. Seemed like TestComplete would just get tired and quit reading the mapping and then we would start seeing the Windows info instead of the mapped names. We tried to track it down but it was taking too long and we couldn't reproduce it at will, so we just learned to reboot when it started happening because it was going to crash eventually and that was the quick solution. Haven't seen it in a while, but we've been working with the same name mapping for several months.
Another note, when TestComplete is running slow for us, we can open the mapping for an object and see the Windows info fill in and then switch to the .Net mapping. I'm sure that we just don't see that happening when it's running at normal speed, but that may lend some credence to your theory about the plug-in. - We're not using any sort of name mapping. Just calling the object.Find function to find controls and interact with them. This looks like a bug with Test Complete.
- I was able to find a "fix" for this by increasing the projects auto wait timeout to be greater than the applications "non-responsive" load time. What appears to be happening is that the .Find method achieves the autowait timeout and then causes the .Net plugin to fail.
Pseudo code to reproduce:
1. object.Click();
//Long application load that causes the application to become non-responsive
2. object.Find(prop,propVal,depth);
3. autowait timeout is reached (application is still non-responsive)
4. application finishes processing and is now responsive
5. .Find method failed to find the object due to auto wait timeout being less than the applications load time.
6. Extended properties are unavailable until the plugin is reinitialized, Test Complete is restarted, or the test application is restarted.
Hopefully someone else finds this useful, or someone at SmartBear can reproduce the issue and get this fixed in a future update :). - TanyaYatskovska
Alumni
Hi Ryan,
As far as I understand, TestComplete works correctly in this situation. The app form is loaded longer than TestComplete is waiting for it. Try using the following code to get the application's main form:
[JScript]
function getMainForm(timeout)
{
// Default timeout is 60 seconds
if (null == timeout) timeout = 60000;
var proc = Sys.Process("Infinity");
var mainForm = Utils.CreateStubObject();
var oldTimeout = Options.OpenApps.InvokeTimeout;
var endTime = GetTickCount() + timeout;
while (GetTickCount() < endTime) {
mainForm = proc.WaitWinFormsObject("frmCATFRAMS", 0);
if (true == mainForm.Exists) break;
Delay(200);
// This line resets the object tree
Options.OpenApps.InvokeTimeout = Options.OpenApps.InvokeTimeout + 1;
}
Options.OpenApps.InvokeTimeout = oldTimeout;
if (false == mainForm.Exists) {
Log.Warning("Unable to get the main form object.");
}
return mainForm;
}
The VBScript version of this sample is located http://smartbear.com/forums/f81/fp6/t74310/incorrect-object-names.
- Tanya,
My workaround was to increase the timeout manually in the project settings and your code here appears to be increasing the timeout programmatically. Effectively using the same workaround, but not addressing the underlying issue.
Not sure how increasing the invoketimeout (Options.OpenApps.InvokeTimeout) has anything to do with the Object tree?
I'm specifically referring to the comment that says:
// This line resets the object tree
Options.OpenApps.InvokeTimeout = Options.OpenApps.InvokeTimeout + 1;
Can you elaborate on this please? - TanyaYatskovska
Hi Ryan,
The playback timeout and the method invoke timeout are different settings in TestComplete. I specified the Method invoke timeout option in the code. It identifies how long TestComplete will wait until the application is ready for testing (until it becomes "Open").
- Tanya,
I was skeptical so I gave this a try.
Predictably this proposed solution had no impact on the issue I am experiencing.
If the .Find method times out during CPU intensive application processing extended properties are no longer available. I am still unable to work around this without setting the Auto-wait timeout to a value greater than the applications process time. From your code the "mainForm" in this scenario does exist, but is currently "Unresponsive" while processing....during that "Unresponsive" state I am performing a .Find on the form...
(mainForm.Find(prop,propVal,depth) )...the Find method appears to be waiting up until the auto-wait timeout and then causes the .Net plugin support to crash or become unavailable. [removed]
[removed]
