eValid™ -- Automated Web Quality Solution Browser-Based, Client-Side, Functional Testing & Validation, Load & Performance Tuning, Page Timing, Website Analysis, and Rich Internet Application Monitoring.

Summary
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?

• Use of Absolute Screen Commands
  In most cases when you use F11 to record clicks into an application because it does not respond to regular clicks (i.e. those accomplished within HTML), eValid writes a passage like the following:

  	...
  	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!

• Commands with Built-In Lock/Unlock
  eValid commands such as xyLClick have a built-in Lock/Unlock to assure that the copy of eValid issuing the command has exclusive access to the desktop during the period when that playback occurs.

• Playback With Minimized eValid Browser
  In most cases eValid can play back a script that does not involve screen access in fully minimized form. You can confirm successful operation of such a script by first minimizing the eValid browser, and then using the eValid Dashboard to start playback. Or, you can edit a Minimize into the script to force the minimization. You may wish also to edit in a Restore to restore the eValid browser face.

• A Note About Focus
  eValid senses if a window is "in focus" using an internal "is this window in focus?" query, or by running a Focus command.

  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.

• Limitations of Error Recovery
  At this point you might ask, "Why don't you program eValid NOT to do that? Why don't you make eValid smarter?"

  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.

• Summary of Desktop Mode Behavior
  The table below summarizes the situation for the indicated combinations.

  Type of Desktop	State of Screen	Desktop Access Not Required	Desktop Access Required
  Local Desktop Normal Operation	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.