← Back to team overview

sikuli-driver team mailing list archive

Re: [Question #270538]: Is there a way to remove the sikuli import feature in the nightly build?

 

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.