SikuliX

SukuliXIDE : Mojave : Robot Framework : Can't seem to activate a text entry field

Asked by Melvin Raymond

- Using SikuliX IDE with Robot Framework on Mac Mojave OS
- Python 2.7.10
- Jython is being used
- Java SE 8 installed

Hi RaiMan.

I've had a little time to pick at this again yesterday, and I had this goal to get a "def" piece working to get my application setup. This is what I'm currently doing:

- Invoke my Viewer app (success)
- Activate the Text Entry field (not successful here)
- Type the word "test" into the field (I think I can do this if I get the last Sikuli piece to work, "test" is the WIFI name of my device)
- Then some other clicks to get the rest of it setup (I think I can easily do these 'most likely')

The problem: I can't seem to get the Text Entry field to work. When I run this script I can see that it does actually click on the field. You can see the image I'm clicking on here though because pasting it here converts it to some numerical value, but it essentially says "Enter Name or IP" in gray text there. So the SikuliX does see that. When I click on this field manually, it puts your cursor into the field (which I want it to do so I can enter the 'test" text. It also outlines the field for the user so they have a visual that it's been selected. When I run the following script though, I don't seem to be able to activate that field. I've tried double clicking and some other things. The wait time isn't very long when clicking it manually. It highlights fairly quickly. I've added a piece after that to enter the text but it never happens. Note also I've commented out the Teardown so my application stays up.

runScript("""
robot
*** Variables ***
${TESTAPP} "/Applications/Viewer.app"
#${APPTITLE} "LabQuest Viewer 2.0"
*** Settings ***
Library ./inline/LabQuestViewer

*** Test Cases ***
Test Robot Framework Logging 1
    [Setup] Setup Actions
    Log Test Logging 1
   # [Teardown] Teardown Actions

*** Keywords ***
Setup Actions
    Log Setup Actions done here
    prepare my application ${TESTAPP}

Teardown Actions
    Log Teardown Actions done here
    stop my application ${TESTAPP}

""")

class LabQuestViewer(object):
  def prepare_my_application(self, myApp):
    App.open(myApp)
    click("1551743399148.png")
  def stop_my_application(self, myApp):
    App.close(myApp)

Question information

Language:
English Edit question
Status:
Solved
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Solved by:
Melvin Raymond
Solved:
Last query:
Last reply:
Revision history for this message
RaiMan (raimund-hocke) said : 		#1

It would be much easier, if you just send me a zip containing your .sikuli and a screenshot of the situation at the time the script stops running.
send to sikulix---at---outlook---dot---com

Revision history for this message
Melvin Raymond (fribian) said : 		#2

OK, that sounds like a great idea. I'll get one sent sometime today if they don't pull me off into a project. If they do, I'll eventually get one to you. I'm sure it'd help a lot to actually see what it looks like.

Revision history for this message
Melvin Raymond (fribian) said : 		#3

OK, I managed to get a screenshot captured and emailed Railman. Thanks for quick turn around.

Revision history for this message
Melvin Raymond (fribian) said : 		#4

I think I fixed it. I was wondering if it had a timing problem and some wait state wasn't enough somewhere in the defaults. So I put in a:

wait(10)

Then I exited the SikuliX IDE and restarted it.
When I ran the script with the wait(10) in it, it worked and even typed the text into the field. So it looks like a timing issue which is typical of automated stuff. I was assuming too much about the default wait states of the new SikilX I think.

I'll go ahead and close this now since I've got it working. In the meantime I'll tinker with the length of the wait states.

Revision history for this message
RaiMan (raimund-hocke) said : 		#5

Ok, yesterday I had "closed my office" already: evening time in Germany ;-)

Looking at your setup and your description, I also had the idea of some timing challenges.

Since SikuliX only sees pixels on the screen and cannot check, wether a click really did what it should, there are some situations, where only a usually short wait can help:
- the app window already shows the wanted image on the screen, but is not yet really ready to accept user actions
- the GUI accepts a click, but the target GUI element has some internal delay until it is ready for the next action

you might have both (pseudo code):
App.open()
wait(2) # usually 1 up to some seconds
click()
wait(0.5) # usually 0.3 - 0.5
type()

Revision history for this message
Melvin Raymond (fribian) said : 		#6

Thanks RaiMan,

I now have a complete [setup] and [teardown] that starts the app, connects
the hardware via WIFI, maximizes the image of the connected device. Then
the teardown sets it all back up to a default state, and closes the app. So
now I'll be simplifying the script as much as possible and tweaking the
timing. I was able to run the script 10 times in a row without flaw, but
there's still network timing things that happen, but I'm pretty sure
there's other things I can to to wait for specific things to occur (within
some time limit) and post an error if the time limit fails. If the expected
item appears, then I can hit it, and this way I don't have to give a solid
wait time. It's more complex for sure. If feels pretty cool to get this
actually doing something from the IDE with the Robot Framework. I showed
the execution of the script to my manager yesterday. It was pretty fun.

On Tue, Mar 5, 2019 at 11:53 PM RaiMan <email address hidden>
wrote:

> Your question #678976 on Sikuli changed:
> https://answers.launchpad.net/sikuli/+question/678976
>
> RaiMan posted a new comment:
> Ok, yesterday I had "closed my office" already: evening time in Germany
> ;-)
>
> Looking at your setup and your description, I also had the idea of some
> timing challenges.
>
> Since SikuliX only sees pixels on the screen and cannot check, wether a
> click really did what it should, there are some situations, where only a
> usually short wait can help:
> - the app window already shows the wanted image on the screen, but is not
> yet really ready to accept user actions
> - the GUI accepts a click, but the target GUI element has some internal
> delay until it is ready for the next action
>
> you might have both (pseudo code):
> App.open()
> wait(2) # usually 1 up to some seconds
> click()
> wait(0.5) # usually 0.3 - 0.5
> type()
>
> --
> You received this question notification because you asked the question.
>

--
Mel Raymond - Quality Assurance Engineer
<email address hidden>

Vernier Software & Technology

13979 SW Millikan Way

Beaverton, OR 97005

www.vernier.com

Revision history for this message
RaiMan (raimund-hocke) said : 		#7

Allways a pleasure to get such feedback.

All the best on your further was with SikuliX.
Always welcome.