ContributionsMost RecentMost LikesSolutionsRe: Handling Object Changes mechanism from one to another build in the desktop applicationYou could try to use the Find method to access objects: https://support.smartbear.com/viewarticle/73101/ As long as e.g. the value of the Name property does not change from one build to another, you can search for the object by its Name property, and you do not have to take care of any changes in the object hierarchy. Regards... JensRe: Problem accessing mainform window Hi Alex, Thanks for your reply, it´s the same that we were advised by the support team. SetFocus() on a form works for us usually - but not in this case. It's no problem to use Activate() instead of SetFocus(), but it bothers me a bit that we have to use Activate() everytime when we start a tested app to prevent that occasional error. Anyway, it is working now. Thanks... Best regards Jens Schwarz Re: Problem accessing mainform window Yes, the problem still exists. We've already contacted Smartbear Support to find a solution. We do not use name mapping at all. Best regards Jens Schwarz Problem accessing mainform window Hi all! Since we migrated our testing machines to Windows10, we sometimes encounter problems using TestExecute (v11.31). After our application is started, the mainform does not seem to have the focus. Calling the SetFocus() method on the mainform results in this error: "The window cannot get focus." Calling Sys.Desktop.ActiveWindow() results in an exception "Cannot find the window with handle 1234." Once this error occurs, it is a permanent error (when I try Sys.Desktop.ActiveWindow() again after a minute, it will result in the same error). It is not always reproducable. I do not see anything else on the Win desktop except for the main window of our application. I'm not sure if Win10 causes this problem or not, but I think we did not see this on Win8.1. Does anyone have an idea what may cause this? Best regards Jens Schwarz SolvedRe: Handle application freeze When the OnLogError event is fired, the app already has been terminated automatically, so this is too late. I need to take an action before the app is closed. Handle application freeze Hi all. I wonder if there is a possibility to control what happens if TestComplete encounters an application freeze (set at project options > Freeze Diagnostics). TC detects a freeze properly, but then terminates the application automatically. How can I interfere before the app is terminated ? A timeout event is not triggered when an app freezes. Best regards... Jens Problem with tcMSAAAppHook.DLL Hi all. We are controlling an application that we test with TestComplete through MSAA. When our application terminates, we experience access violations in the context of the application, in “tcMSAAAppHook.DLL”. We suspect that TestComplete still has a reference on an MSAA COM object, but this reference is of course getting invalid when the application terminates. What is the best practice to handle this situation? Is there a way to force TestComplete to release all MSAA references, so that we could do this before terminating the application? Attached is a callstack, as you can see, our application is not involved. Best regards... Jens Re: Modal dialog is sometimes not focused after it´s opened Hi Ryan, thanks for your answer. We will try this for one of our products and hope that this issue will be solved. Do you know how to handle this in .NET ? Best regards Jens Modal dialog is sometimes not focused after it´s opened Hi all, Sometimes we are running into this problem: TestExecute opens a modal dialog (e.g. a properties dialog) on the main form of our application. After that, the main form is still focused, and the modal dialog is on top of it (Sys.Desktop.ActiveWindow returns the main form in this case). Expected behaviour is that the modal dialog is focused. When I try this manually, the modal dialog will always be focused (and it is impossible to focus the main form) as intended. This occurs for .NET and Delphi applications, TestExecute version is 10.5. Does anyone have an idea what could cause this? This behaviour does not always occur. Best regards Jens Re: TestObj.FindAll()That seems to be the solution! Thanks a lot !!!