Question #270538 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/270538
Ryan posted a new comment:
Yes we are still talking 1.1.0 with the issue, sorry. I was describing
the existing way that Sikuli is launched in reference to the question
about using the .sikuli folder. In the case of finally switching to
1.1.0 that line would be changed, however I was only running my testing
through eclipse at this point.
I'm not sure why the traceback wouldn't correlate to 1.1.0 but I made sure to
remove all of the existing sikuli data and re-install clean. I actually updated
to the final release of Jython at the same time, so I know the jythonpath was
cleared of old modules as well.
In that example I attempted to find the image before passing it off to the
other object and it was successful, and printing the image/pattern within the
object that is supposed to look for it showed the filepath. I was even able to
use the region itself within that object, but only when it was self.find(img)
did it return that error.
What I have been doing is operating under the assumption that, except in
special cases, an object will not be called without knowing it's region on the
screen. For example, after creating a region containing a text box based some
find operation, that region is passed into TextBox:
class TextBox(SomeSuperClass):
def __init__(region, name=TextBox):
"""@type region: Region"""
super(TextBox, self).__init__(region, name)
# Anything else the Text Box needs
def severalMethods():
do stuff
region is assumed to be a Region in some capacity and even if it is one
of my existing objects, type-hinting in the docstring helps assume it is
some kind of Region. Eventually there is a super class that instantiates
the region:
class BaseClass(Region):
def __init__(region, name, sikuli=sikuli, lookup=None, curDir=None):
super(BaseClass, self).__init__(region)
self.region=region # Actually wrapped in a property with a depreciation
warning to keep backwards compatibility between our frameworks.
def methodsIHaveAbstracted():
do stuff
In the specific case of my issue, the constructor received it's own Region as
region (and calls the init of the super providing this region) and then
attempts to use the find method found through inheritance to search for this
button. This is where I try self.region.find(img) or even just region.find(img)
(should be the same anyway) and am able to find the region.
Are you saying that instead of the BaseClass using
super().__init__(region) it should be using Region.init(region)?
While reviewing what I wrote above I tried some things. I printed out
self.getX() (and y, w, h) and received 0, 0 900, 1600 as expected (the region
is the entire screen). I then tried to do self.highlight(3) on the next line
and logged the following:
2015-08-20 08:49:04,789 DEBUG - __init__:60 - (<type
'java.lang.NullPointerException'>, java.lang.NullPointerException, <traceback
object at 0x2>)
Sorry to keep at it, I'm just going to need to prepare a description of
what is and is not possible in the new version to my team so I want to
make sure I understand the changes and limitations. My goal was run
exactly what I have in place in 1.1.0 and see what breaks and then go
from there.
--
You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.
_______________________________________________
Mailing list: https://launchpad.net/~sikuli-driver
Post to : sikuli-driver@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sikuli-driver
More help : https://help.launchpad.net/ListHelp
