eValid live recordings or eValid scripts edited from recordings often make use of the windows desktop. This page identifies some of the issues surrounding how eValid interacts with the current desktop. What happens if the eValid browser is minimized, or if the requested window is not in focus, or if for some other reason eValid can't reach the desktop?
... WindowPos 0 150 12 350 600 xyLClick 0 450 250 0 NAV ...On playback the WindowPos command will force eValid to bring window 0 to the correct screen location (including, to bring it out of a minimized state). This is done to ensure that the xyLClick command has meaning and that the click will be issued in the right place on the screen. The NAV tag assures that the command will wait for the resulting navigation activity before continuing.
But consider what happens if you change the script manually to read:
... Minimize 0 # WindowPos 0 150 12 350 600 xyLClick 0 450 250 0 NAV ...On playback eValid will minimize window zero, and try to issue an xyLClick but not having a window to issue that click into, eValid just waits. The window got minimized but did not get restored, so there's "no window" for eValid to send the xyLClick event to. So eValid waits; it does exactly what it was told to do so it obeys the instruction!
The operating system may say that a window is in focus, but the window may not actually arrive in that state. This can cause problems if, immediately after requesting focus, eValid tries to scrape something from the screen. eValid can "get ahead of" the operating system, and scrape not-yet-updated information (the wrong information). Commanding a short delay, e.g. Wait 500, usually overcomes this and prevents de-synchronization.
The answer of course is that we can never build into eValid enough protection against all of the non-normal scripts that users could write. Of course, we do build protection against certain of the most obvious kinds of mistakes, but that still doesn't prevent inadvertent use of script passages that cause unusual behavior.
Expressed in programming terms the argument goes this way: if you think of eValid as a script interpreting engine -- which it actually is for valid playback scripts -- you would be asking eValid to understand the intention of the "program" [the script] and to act accordingly. It's not possible to program eValid for these kinds of possibilities.
Instead of trying for the impossible, eValid performs basic sanity checking of the script before executing it, and enforces certain kinds of general "completely insane" error detections. The bottom line on reliable script playback is the user: eValid ultimately relies on the tester to carefully watch eValid playing back each script with the actual conditions under which is it supposed to be used, and to confirm that it operates correctly.
|Local Desktop |
|eValid window normal||OK||OK|
|eValid window as shrunken mini-screen*||OK||Failure possible if there are clicks onto the screen but where the "mini-screen" is not positioned correctly.|
|eValid window minimized with "_"||OK||Failure likely because any desktop access will never reach the required screen.|
|Remote Desktop |
Via RDC Connect
|Normal [full screen view of the remote desktop]||OK||OK|
|RDC window set as shrunken mini-Screen*||OK||OK because the mini-screen still has scroll bars to allow the remote viewer to see the entire screen.|
|RDC window minimized with "_"||OK||Failure likely because any desktop access will never reach the required screen.|
* Note: A "mini-screen" -- or shrunk screen -- means that the corresponding window is NOT minimized using the "_" option, but instead is made as small as possible without minimizing the screen. When as small as possible you still see the window type, minimize, maximize/restore and close options. A mini-screen window is NOT found in the tool tray at the bottom of the screen.