ContributionsMost RecentMost LikesSolutionsRe: Send the stop test execution signal to TC from another script "Outside of the TestComplete environment" that is what I mean by external script! Thank you! Send the stop test execution signal to TC from another script When a test is running in TC/TE, there's a pause and stop button in the upper right corner of the screen. I would like to trigger the same stop signal as the stop button does from an external script. Is that possible? Kind Regards Christian Olsson SolvedRe: Property Wait to avoid Window destroyed error on Activate This application is started and terminated several times in the test therefor it's possible but not certain that this is the cause :smileyhappy: Re: Property Wait to avoid Window destroyed error on Activate Thanks! At least I know that there's (probably) not an easy solution that I'm missing. Re: Property Wait to avoid Window destroyed error on Activate It does not work better without the Refresh, the infrequent error (The window was destroyed during method execution) occurred again on the new version of the test which does not have Refresh and has an Exists check. If this problem is ever solved then I'll get a nice "aaaah" feeling :smileyvery-happy:. Re: Property Wait to avoid Window destroyed error on Activate "The object is found" is that equivalent to object.Exists = True? I have removed the "Refresh" Kind Regards colsson Re: Property Wait to avoid Window destroyed error on Activate For some unknown reason FindChildEx does not work while FindChild does work. (TestComplete 9) Using FindChildEx would have been an improvement but it is not crucial. Your description of the cause of the problem makes sense. The .Refresh function is called on the function between finding it and calling .Activate on it, that could be the cause of this error which only happens infrequently. I could not find anything to wait for to give an indication that the application is ready, I was hoping to find some corresponding property in TestComplete. Re: Property Wait to avoid Window destroyed error on Activate What is the advantage of using WaitChild over FindChild? FindChild offers the searching capability of named property values compared to WaitChild which offers wildcard search, what if the search has to be done through FindChild would you then use WaitChild on the found object? Set result = Utils.CreateStubObject Set obj1 = obj.FindChild(...) If obj1.Exists Then Set result = obj1.Parent.WaitChild(obj1.Name, timeout) End If Re: Property Wait to avoid Window destroyed error on Activate Good explanation of the "wait" methods! I would still like to be able to wait for some "CanCallActivate" property on the child object though. Thank you for the suggestion of changing FindChild to WaitProcess / WaitChild! I will try that. Activate is used to ensure that the window is on top. Kind Regards colsson Re: Property Wait to avoid Window destroyed error on Activate I should have been more detailed in my previous answer! I can access the parent object, but I do wonder why the parent is needed to wait for a particular state of the child? The chain leading up to the Activate call which in turn causes a problem: Set process1 = Sys.FindChild(...) If process1.Exists Then Set child1 = process1.FindChild(...) If child1.Exists Then child1.Activate 'Works most of the time but may cause Window destroyed error End If End If process1 is: "msiexec" child1 is a Form in the "msiexec" Can you help me with that piece of code?