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

Introduction
This page addresses the details of how to handle server loading when scripts require desktop access.

1. Single script. If you have only one script that needs the desktop during playback then you don't have a problem.
2. Multiple non-competing scripts. If you have two [or more] scripts that run simultaneously, and they don't compete at any time for the same part of the desktop, then you also don't have a problem. A's interaction with the desktop involves different locations on the desktop, so the two processes will run fine independently.
3. Multiple engineered non-competing scripts. If you can arrange it, which may be possible for a small number of scripts, you could allocate various sections of the screen to each of the scripts' desktop interaction. Then each of the independent eValid playbacks will be separated geographically on the desktop so there will be no interference.
4. Multiple competing scripts. In this case, when two [or more] scripts necessarily must use the same desktop locations, then you need to use the Lock/Unlock command to prevent unwanted interactions. (That is, you want to prevent A's clicks to the desktop being set to B's copy of whatever is on the desktop, with potentially erroneous effect.

Screen-Based Synchronization
In general, all screen-based activity, including synchronization steps, should be avoided. The desktop time line can only be divided so many ways.

The synchronize on text or URL commands, SyncOnText, SyncOnURL, are OK to use because they can run OK with eValid minimized; there is no desktop activity needed.

But in most cases a synchronization step that uses a desktop image with the xySyncRec command requires lengthy exclusive use of the desktop. You'll have to Lock/Unlock around that and that process may limit the total number of copies of eValid that can run simultaneously. You can only divide the desktop time line up so many ways!

Remember, if one script is very slow to synchronize then the time taken to synchronize that step may interfere with the maximum loading capacity of your LoadTest scenario.

Lock/Unlock Command
Here is the script documentation for the Lock/Unlock Command.

1. Command Syntax
   
   Lock
   Lock [n]
   Unlock

2. Explanation
   The Lock command is used to lock the current eValid window in the desktop foreground to facilitate working with ModalDialogs, to provide for unique access to cache data, and to prevent other eValid's commands that require window focus from interfering with the current playback.

   Any concurrently executing eValid windows that use the Lock & Unlock commands will wait until there are no windows locked (i.e. in focus) before proceeding.

   Lock can take an optional number parameter that specifies the number of milliseconds before the lock times out. This is only effective if no Unlock command is given or if the Unlock command is not reached before the timeout. If no parameter is given a default of 60000 msecs (1 minute) is used.

   The Lock & Unlock commands are essential for scripts that involve ModalDialog commands, or for scripts which require focus to be maintained on a particular window. The block of eValid playback script commands that need to have exclusive focus locked should be wrapped in a Lock ... Unlock block, for example:

   ...
   Commands...
   Lock
     SubmitClick [parameters]
     ModalDialogWait 4000
     ModalDialogEnter
     ...
   Unlock
   OtherCommands...
   ...

   Lock & Unlock can be used at other times to ensure that the script runs in the foreground and all other eValid processes will wail until no other eValid windows are locked before continuing script playback.

   Note 1: AbsMouse and Keyboard events implicitly lock the playback process for the duration of the command. However, use of Lock/Unlock will enhance the reliability.

   Note 2: SyncOnScreenRect locks the playback process before each attempt to validate the screen, and releases it after each attempt. It will NOT lock the process for the whole time it is attempting to validate. It will also be released when the validation has succeeded or has timed out. This allows multiple validations in different scripts to work concurrently.