sikuli-driver team mailing list archive

[RaiMan <question242935@xxxxxxxxxxxxxxxxxxxxx>]

Question #242935 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/242935

RaiMan proposed the following answer:
comment #1 is the right approach, to fix the problem, but usually in these cases
wait(0.3) 
is sufficient.

With version 1.0.1+ there is a convenience:
Settings.ClickDelay = 0.3
click(some_image_or_pattern)

or to make it more visible in the code:
Settings.ClickDelay = 0.3; click(some_image_or_pattern)

This just internally inserts a short wait after the mouseDown internally
(as in comment #1) and only applies to the next click.

*** The background:
Some app specific GUI's have a short delay after the mouse enters an element before accepting a click. This often comes together with some tooltip-like display of information. 
Others need a delay between mouseDown and mouseUp to interpret this a s a click. This depends on implementation. 
And there have been situations, where the implementation had some flaws, so depending on cpu usage and parallel processes these delays varied (which should be taken as a bug ;-).

so the general "mouse-flow" for a click can be seen as this:
hover(target)
wait(x)
mouseDown()
wait(y)
mouseUp()

where x and y usually are 0 or in some cases some 10 milliseconds
(usually < 300).

For the y value we have the above mentioned convenience with version 1.0.1
hover(target)
wait(x)
Settings.ClickDelay = 0.3; click(some_image_or_pattern)

-- 
You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.