sikuli-driver team mailing list archive

[RaiMan <question251026@xxxxxxxxxxxxxxxxxxxxx>]

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

    Status: Open => Answered

RaiMan proposed the following answer:
Handling popups in parallel, that need any keyboard or mouse action, to
get them vanished or to background, is one of the biggest challenges in
Sikuli.

One possible solution is to setup some adequate observe()s. But until
version 1.1.0-BetaX, this feature has some bugs and oddities.

The other possibility is to make your own observer script using the
standard features of Sikuli and let that run in a thread in parallel.

A possibility in between is, to have a snippet (some function), that
checks all possible popup situations one after the other and handles
each one. This function is called before critical parts of the workflow
(but still a risk to be disturbed by a popup).

The main challenge is coordination of main workflow and observer task in general, but especially with respect to mouse and keyboard usage:
- the main workflow has to know, when to pause/resume, because it might not make sense to proceed on account of a popup
- the handling of the popup might steel the mouse and/or keyboard from the main workflow with unpredictable consequences. In versions before 1.1.0 this might even happen inside a multistep mouse action, which might even lead to Java crashes.

Beginning with version 1.1.0, it is possible to block the mouse for exclusive usage (so other mouse actions happening in parallel have to wait) and detect when the mouse was moved by another process or the user (different actions are possible then including a call back function/handler). This will make it much easier to tackle this situation properly.
Caveat: 1.1.0 is still in beta and the fetters are only poorly documented.

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