[1.1.4] getWords() and getLines() not working --- must be collectWords/collectLines

both functions are currently only useable as someRegion.getXXX (e.g. SCREEN.getWords())

Hmmmm. I knew that, but perhaps I've mismatched a datatype somehow. So here is a bare minimum code block I used to test (and it still failed):
---------------------
new_reg = selectRegion("Pick a text area...")

print new_reg.text()

print new_reg.getWords()

print new_reg.getLines()
---------------------

The first print works, and outputs the text. The second one fails (no attribute 'getWords'), and the third fails in the same way if I comment out the second. Should this work?

By the way, thank you so much for all of your incredible work.. SikuliX truly is an awesome piece of software!

Woops - forgot to flag the last comment.

Thanks for your feedback and coming back on this.

You are right.

The original function names where getWords and getLines, but that gave some strange naming clashes at the Python level.

So I renamed them to
collectWords and collectLines

... have to revise the docs. (done ;-)

Awesome! The function calls no longer fail....

But just want to clarify one last thing, to be sure I understand this is working as intended for both the collectWords() and collectLines() functions. Should these return the actual text as elements within the list, or the match object for the text elements resulting from the function call?

Example:

new_reg = selectRegion("Pick some text") #<--- the actual text in the image capture reads "This is a test!"

print new_reg.text() #<--- This returns properly "This is a test!"

print new_reg.collectWords() #<--- This returns a string type list with 4 "match" objects
# Example result:
# [M[145,57 63x22]@S(S(0)[0,0 1366x768]) S:0.88 C:177,68 [-1 msec], [etc for 2nd match], [etc for 3rd match], [etc for 4th match])

new_str = new_reg.collectWords()
print new_reg[0].text() #<--- This returns the value of the "match" object... in this case, the word "This"
print new_reg[1].text() #<--- Returns "is"
print new_reg[2].text() #<--- Returns "a"
print new_reg[3].text() #<--- Returns "test!"

--------------------------
Is this as expected, from your perspective? If so, the documents should probably reflect that the returned result is a list of Match objects, shouldn't it?

Just making sure I understand it! Thanks again for the rapid responses and all of your great work!

Honestly, I can see the advantages to both...

If it was the actual strings, more easily capture the "data" you want to use or manipulate, with more easy code / less steps.

If it was the matches (as it is now), you can still get the strings.. it just needs some additional programming by the user. Also, the additional .text() calls will add to the processing load, I expect (instead of the functionality being done in one shot, behind the scenes). Though the big advantage here could be the ability to act on the 'match' data to get things more easily (like pixel height / length of text, etc) and use that for some more inventive functionality.. and only use the additional .text() calls as necessary.

The user in me likes the first option, returning strings vs matches....

... but the programmer in me likes the *second* option, due to the capabilities it gives.

Thanks RaiMan, that solved my question.

No need to make an extra match.text().

The match object has: match.getText() (the read text is stored there during collectXXX)

Nevertheless: I think a variant, that returns List<String> should be helpful in some cases

added: Region: collectWordsText() and collectLinesText() returning List<String>