getting "capture_screenshot takes exactly 2 arguments (1 given)" error

[spooning]

Originally submitted to Google Code by bryan.oakley on 14 Feb 2011

We subclass SeleniumLibrary to add some unique features, and once I upgraded to version 2.5 or 2.6 of the selenium library I started getting the capture_screenshot error mentioned in the summary.

Part of the problem seems to be that both selenium.py and screenshot.py in the SeleniumLibrary implementation has a 'def capture_screenshot', one with an optional second arg and one with a required second arg. For reasons I don't yet understand, my subclass appears to be inheriting the wrong one.

Is it a bug that capture_screenshot is implemented in two places?

[spooning]

Originally submitted to Google Code by @pekkaklarck on 15 Feb 2011

It's pretty impossible to know what goes wrong without knowing where error occurs and seeing the traceback. Having an example to try out would help debugging even more.

My guess is that this is somehow related to the metaclass used to register the keyword to run on failure. Having capture_screenshot method in two places, when the other one helper module, shouldn't have anything to do with this.

Bryan, since you set yourself as an owner of this issue it looks like you would do something to it.

[spooning]

Originally submitted to Google Code by bryan.oakley on 15 Feb 2011

I think you missed the point.

There are two implementations of capture_screenshot, which looks like a bug to me. One requires two arguments, one requires one argument and has a second optional argument. Shouldn't there be only one implementation of capture_screenshot, and if so, which is the right one?

[spooning]

Originally submitted to Google Code by @pekkaklarck on 15 Feb 2011

No, I don't think I missed the point.

Yes, there are two different methods named capture_screenshot in the code base. This should not matter because only the one in screenshot.py ends up being a method of SeleniumLibrary itself via multi-inheritance. The one in selenium.py is part of the Selenium API that is used by various keywords but not directly inherited. If you don't believe my words, you may believe the code:

>>> from SeleniumLibrary import SeleniumLibrary as SL >>> for cls in (SL,) + SL.bases: ... print cls.name, ... print 'YES' if 'capture_screenshot' in cls.dict else 'no' ... SeleniumLibrary no Browser no Page no Button no Click no JavaScript no Mouse no Select no Element no Screenshot YES Table no TextField no Flex no

I'm sorry for not being more explicit about this in my first comment, but I though you knew how the library was organized.

[spooning]

Originally submitted to Google Code by @pekkaklarck on 22 Feb 2011

Were you able to figure out what went wrong? Is there anything that should be fixed in the library?

[spooning]

Originally submitted to Google Code by bryan.oakley on 22 Feb 2011

No, I haven't been able to figure out the specific problem, though it appears to be related to how we are subclassing SeleniumLibrary.

I think we can close this.

[spooning]

Originally submitted to Google Code by @pekkaklarck on 22 Feb 2011

Ok, closing. I'm pretty sure the problem is somehow related to the metaclass that implements the run_on_failure functionality that was added in version 2.5. Instead of subclassing, you might want to consider extending the library using BuiltIn.get_library_instance: http://robotframework.googlecode.com/svn/tags/robotframework-2.5.6/doc/userguide/RobotFrameworkUserGuide.html#getting-active-library-instance-from-robot-framework