I like to debug those types of problems with a screen capture. That's the only way I can tell what exactly is going wrong. Reviewing the screen captures then I can often refine what I use in the WaitProperty statement to get better results. Below is an example of my approach. Maybe it will help, maybe not. At least you'll be able to see what's happening.
Set wnd = MyApplication.MainWindow
If Not wnd.WaitProperty("Enabled",True,5000) Then
Log.Warning "The application and/or target window is disabled"
Set w = Sys.Desktop.Picture
Log.Picture w, "Screen capture showing disabled window"
End If
Hi,
Below is an example of my approach.
Actually, unless test code interacts with MyApplication.MainWindow, your sample code will not provide you with any help as it checks the state of MainWindow object only.
Unless you are using latest TestComplete version and something was broken in it, "The window is disabled. [...]" message was always correct and meant that the target window is disabled and end-user cannot interact with it.
You can get the name of the problematic window from Details pane of test log.
Considering, that the problem is intermittent, it might indicate timing issue when your test code proceeds fast enough and target window/UI control that was blocked by, for example, some modal notification window, are not enabled back by system or your application's code.
To resolve the problem: figure out exact window/control that is reported as disabled and then analyze how tested application behaves when it reaches this state and what does your test code. Ideally, it might help if you have an option to talk to developers and they can provide you with description of how windows/controls of your tested application are disabled and enabled for this tested functionality.
I should have clarified it was intended as an example. You would need to substitute the appropriate window identification for "MyApplication.MainWindow".
