Ok, please let me correct and/or clarify myself on this issue. I have a block of code as follows:
If Wait(10, "ServerOpts_AuthSuccess", tpWaitSeconds) = True Then
TestLog.Comment "Server Options Authenticated"
Window("G-Station Server Options Window").Attach
This conditional checks for the existence of a window indicating a successful connection within 10 seconds. The rest of the details are described in my original post. The correction is when I put a watch on the Wait statement, it evaluates to True, but the code executed is in the Else block as if the condition were False. The attached file shows the "illogical" flow as I put breakpoints at the beginning of each conditional block (IF and ELSE). Why does this happen and how can I avoid this confusion?
This would fit with my experience of events in TP... they have not been reliable for me and I avoid them at all costs. While the Attach functionality and time-out works just fine, when combined in a Window (or any) event the results are not reliable.
Another possibility is that the event is designed to be True when the window does not exist or goes away. You would only see that in the event definition.
If the event definition is correct, it appears to be some type of bug. I'd be interested to hear what MF support has to say about it.
A problem is a difference between what is perceived and what is desired, that
we want to reduce (Dewey 1933)
When creating solid, repeatable test I use screen events and not window events. The reason is that window events work off of window messages. This is to say that in your case of the exists, a window announces to the O/S that it exists only once. It is not repeated. By default TestPartner's polling of window messages is every 1 second. This means that every other second TestPartner is not "listening" and if the exists message happens during that not listening second it appears that TestPartner does not catch the message. This is true.
A better practice would be to use the screen event. This makes use of the attach name of the window as well as the windows existence. This will allow TestPartner to find the window during it's polling and for the event to return as true.