|
|
Summary
eValid scripts have the capability to access the driver machine desk-top.
Most playbacks don't need exclusive access to the desktop,
but in some cases they do.
In addition, some playbacks need not only
exclusive access to the desktop but need
some kind of playback synchronization.
To prevent loss of playback coherency between multiple independent playbacks requires that the script be engineered to be "desktop safe". Doing this will assure that two [or more] simultaneous playbacks do not interfere with each other (step on each other).
Serialization Limitation
Assuring parallel operation between/among eValid instances
that run non-desktop-safe scripts (see below)
effectively
serializes them in time as they effectively divide the desktop timeline
so that no two of them can conflict.
When two (or more) scritps ARE desktop safe then there usually
is no problem in running them in parallel -- the can even be run
minimized -- assuming there is sufficient CPU power to sustain the load.
The Sure Test for Desktop Safe Operation
The surest way to confirm that a script is desktop safe is to:
Screen Access Control
Loss of coherent operation between two [or more] simultaneously executing
eValid playbacks usually occurs when a shared resource is not reserved
for exclusive use by the eValid instance needing it.
An example -- the most common one -- is in conflicted use of the desk-top. There being only one desk-top available, if two eValid scripts, e.g. A.evs and B.evs, both need to click on a window on the desk-top it is important to prevent an incorrect interaction. What you want to avoid is having A's click arrive on B's window.
The best way to do this is to use the available eValid Lock and Unlock commands to bracket the actions that require exclusive desk-top access. The Lock and Unlock commands implement a mutual-exclusion (mutex) logic that: (1) allocates control of the desk-top after a Lock to the issuing playback; which, (2) prevents all other playbacks from issuing Lock commands; until, (3) after the owner of the locked screen issues the Unlock command.
In general the Lock and Unlock commands should be used sparingly. The reason is these commands effectively partition the timeline for the desktop between the set of eValid playbacks that use the Lock/Unlock command. In other words you should use Lock/Unlock to bracket the smallest possible number of commands in each script. The desktop timeline has to be shared among many processes and if the length of time of each process's exclusive access is excessive, there can be very little parallelism.
Sample Script Using Lock/Unlock
While every situation is different and there are many variations in how a script would
be structured, here is a typical pattern that is desktop test safe:
# eValid commands before the synchronizing area. ... # --------------------Start Locked Section----------------------------- # Reserve the screen for exclusive use by this playback... Lock ... # Take the action that requires variable time... GotoLink 0 "Some URL" "" ... # Now, make sure the action is completed before continuing... # ...here a synchronization on a piece of the screen... xySyncRect 0 200 400 123 45 12345678 ... # That proves that the object is present, so now you can # take an action on it reliably... ... # Release the screen for use by other playbacks... Unlock # The desktop is no longer locked, and other eValid's can attempt to # gain exclusive access. # ----------------------End Locked Section----------------------------- |
