Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timeout step changes timeout for browser but not SikuliX #443

Closed
kensoh opened this issue Jun 9, 2019 · 3 comments
Closed

timeout step changes timeout for browser but not SikuliX #443

kensoh opened this issue Jun 9, 2019 · 3 comments
Labels

Comments

@kensoh
Copy link
Member

kensoh commented Jun 9, 2019

In current implementation when timeout step is used, the timeout before error is shown to wait for an UI element, only changes for the web browser and not visual automation.

Users have to use vision step to invoke separately setAutoWaitTimeout(wait_timeout) in SikuliX. TagUI should ideally set browser timeout and SikuliX timeout when timeout step is called.

@kensoh kensoh added the feature label Jun 9, 2019
@kensoh
Copy link
Member Author

kensoh commented Jun 9, 2019

If tagui.sikuli/tagui_sikuli.in exists during execution, then it means SikuliX visual automation is involved. A change can be made in tagui_parse.php timeout_intent() and tagui_header.js timeout_intent() to invoke sikuli_step('vision setAutoWaitTimeout(wait_timeout)').

@kensoh
Copy link
Member Author

kensoh commented Jun 10, 2019

Committed to master. Prior to packaged release, feature available from cutting edge version here -

https://github.com/kelaberetiv/TagUI#set-up

@kensoh kensoh closed this as completed Jun 10, 2019
kensoh added a commit to tebelorg/TagUI that referenced this issue Jun 17, 2019
SikuliX wait_timeout also needs to be changed as part of sikuli_step() when timeout step is used.

Otherwise, when present() or visible() is invoked, the SikuliX timeout setting gets reverted back to its internal variable.

Also, 'casper' object should be used in displaying the error message instead of 'this'. Otherwise, for the execution context, this would be undefined and error message does not show up.
kensoh added a commit that referenced this issue Jun 17, 2019
SikuliX wait_timeout also needs to be changed as part of sikuli_step() when timeout step is used. Otherwise, when present() or visible() is invoked, the SikuliX timeout setting gets reverted back to its internal variable.

Also, 'casper' object should be used in displaying the error message instead of 'this'. Otherwise, for the execution context, this would be undefined and error message does not show up.
@kensoh
Copy link
Member Author

kensoh commented Jun 17, 2019

SikuliX wait_timeout also needs to be changed as part of sikuli_step() when timeout step is used. Otherwise, when present() or visible() is invoked, the SikuliX timeout setting gets reverted back to its internal variable.

Also, 'casper' object should be used in displaying the error message instead of 'this'. Otherwise, for the execution context, this would be undefined and error message does not show up. Above committed PR fixes these issues.

Prior to packaged release, feature available from cutting edge version here -

https://github.com/kelaberetiv/TagUI#set-up

kensoh added a commit to tebelorg/TagUI that referenced this issue Jul 12, 2019
In commit aisingapore@5cba169 from issue aisingapore#443 and PR aisingapore#453 the goal is to also update SikuliX integration internal timeout variable. However there is a bug introduced that makes timeout step hangs if visual automation is not used. Raising an issue to fix this bug with a PR.
kensoh added a commit that referenced this issue Jul 12, 2019
In commit 5cba169 from issue #443 and PR #453 the goal is to also update SikuliX integration internal timeout variable. However there is a bug introduced that makes timeout step hangs if visual automation is not used. Raising an issue to fix this bug with a PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant