Setting Keypressing Delay from Script

[RUDOLF_BOTHMA]

 Morning all,

Quick question this morning.

I'm trying to enforce a minimum key pressing delay in my projects because I just find that too often, the key pressing delay is zero, which causes tests to fail unnecessarily.  All I want to do is go:

if(key pressing delay < 10)
{
  key pressing delay = 10;
}

there is Options.Run.Delay, but that sets the delay between commands, not key presses.  Is there a line of code for the key presses equivalent ?

[AlexKaras · Accepted solution]

Hi,

Two options that I can think of:

a) Set the Project Options > Project|Playback|Runtime|Key pressing delay parameter for the required value (this is a per-project setting);

b) Use [P<delay>] value for keypresses (e.g.: button.Keys("2[P500]0[P500]2[P500]0") )

[Wamboo]

I did a little investigation and I couldn't find a better solution than Alex mentioned.

What you can do in the script is to pack all the actions e.g. .Click with a custom function and in it create some clever script that will execute the desired actions.

[RUDOLF_BOTHMA]

Hi @AlexKaras 

Thanks for the input.  That's about what I thought - It's a shame though.  My reason for trying this is to override user behaviour.  Users go,  "Ooh, the tests are slow, lets decrease this delay"  then inevitably the tests start failing and wasting time investigating false failures.  That second option will work, but, just wow, what a mess to always have to do it - calling a function for no other reason than iterating through a string to add a delay between key presses.  Also users quite often use KWTs without script, so there is no way to implement this in these instances.  Oh well, it is what it is.  More user, um, training required.

[AlexKaras]

@RUDOLF_BOTHMA :

Hi,

Well, I see your reasons and I agree with them.

> causes tests to fail unnecessarily.

What are those failures? Do they happen for every data entry or just for some certain controls?

One more idea that you may try is to use .SetText() instead of .Keys(). Quite often controls misbehave because they expect keyboard input only. In this case you may try, for example, to assign the value via .SetText(), focus the control (using .SetFocus()), move to text end, delete the last character and re-type it.

Something like this (assuming the last character was 'a': <control>.Keys("[End][P500][BS][P500]a[Tab]")

And one more idea:

Emulate user who is pasting data from the clipboard.

Like this:

control.SetFocus()

Sys.Clipboard = <value to enter>

control.Keys("^V")

[RUDOLF_BOTHMA]

---

What are those failures? Do they happen for every data entry or just for some certain controls?

---

They aren't specific to any controls.  Generally they happen when some control just loads a bit slower due to using a different dataset in one of the grids on the page etc.  With DevExpress in Webforms, typing too quickly sometimes breaks combobox lookups, which is why that must be .Keys() with keypressed delay > 0.  We create add-on software.  That means we are quite dependent on how the original software fires and handles events.  Sometimes it just fails for reasons outside of our control. /shrug

---

Emulate user who is pasting data from the clipboard

---

Ooh.  I had never even thought of that possibility in standard testing, not just in the context of this topic.  Thanks

[AlexKaras]

> Generally they happen when some control just loads a bit slower

Somewhere in time when I also had to deal with web controls that were populated with data via a set of Ajax calls, I ended up with the approach to wait until the number of records (list items, table rows, etc.) for the given control stops to change and only then continue to work with the control.