sikuli-driver team mailing list archive

[RaiMan <question678649@xxxxxxxxxxxxxxxxxxxxx>]

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

    Status: Open => Answered

RaiMan proposed the following answer:
Thanks for clarifying the background of your trials.

I fully understand your situation.

... but it is not about threaded clicking, it is more generally the
question, how can one handle independent/asynchronous events happening
on a GUI in parallel and keep the actions done in the handler apart from
the actions done in other handlers.

an example:

def eventDetection():
    # here we check, wether we have to do an action
    # return false if no, true if yes

while True:
    if eventDetection():
        # do the action
    # here we might wait before repeating
    # and might decide to leave the loop

If the event is synchronous with respect to the main workflow, we now
simply wait for the event and handle it, while the main workflow pauses.

With SikuliX features this can be shortened to:

if exists(someImage, someTime): # the event detection
    # do something
else:
    # handle the not found situation

This is how the most SikuliX users build their workflows.

Common asynchronous events are popups, that might happen incidentally during the main workflow, and must be handled, to keep the main workflow running. This usually is done with the observe feature, which can run in parallel (background), and pauses the main workflow, while the event handler does its job.
This feature is sufficient to handle a few different incidents, if the handling is not time critical (reaction time can be more than one second to some seconds). The lower the possible reaction time, the less events can be handled in parallel.

The most challenging event handling usually is with automating games
(game bots). Here in parallel to the main action, you have to watch
different side effects, which must usually be handled in a certain
timeframe.

Yours is a good example:
you have to watch the increase/decrease of some resource and latest at specific thresholds you have to do something, to keep your game running.
... and usually these detection-action-cycles are time critical and you have more than one resource to be watched, that behave independently from each other and in most cases asynchronously.

The general solution with SikuliX:
- relate every independent detection-action-cycle with a Region object (for identification, optimisation, locking, ...)
- detach every detection-action-cycle in a thread (hence they are handled in parallel)
- implement some synching/locking between the threads, to assure the undisturbed completion of an action or at least parts of it.

So clicking a button usually is only one of the last activities in such
a threaded event handling and not the main aspect.

-- 
You received this question notification because your team Sikuli Drivers
is an answer contact for Sikuli.