Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Inheritance #8

Open
stlehmann opened this issue Jun 11, 2015 · 5 comments
Open

Support for Inheritance #8

stlehmann opened this issue Jun 11, 2015 · 5 comments
Assignees

Comments

@stlehmann
Copy link
Contributor

Currently the mapper is not working with inherited QWidget classes. Do you have any plans for fixing this?

Here is my Traceback:

Traceback (most recent call last):
  File "C:/Users/Lehmann/data/python34/ustempctrl/run_ustempctrl.pyw", line 14, in <module>
    w = CtrlTestGui()
  File "C:\Users\Lehmann\data\python34\ustempctrl\ustempctrl\mainwindow.py", line 49, in __init__
    self.plotsettings = PlotSettingsWidget(self)
  File "C:\Users\Lehmann\data\python34\ustempctrl\ustempctrl\plotsettings.py", line 38, in __init__
    self.settings.add_handler('plot/xmin', self.xminSpinBox)
  File "C:\Users\Lehmann\data\python34\pyqtconfig\pyqtconfig\config.py", line 800, in add_handler
    assert False, "No handler-functions available for this widget type (%s)" % type(handler).__name__
AssertionError: No handler-functions available for this widget type (CoordSpinBox)
@stlehmann stlehmann changed the title Inheritance Support for Inheritance Jun 11, 2015
@stlehmann
Copy link
Contributor Author

Not so sure if it is appreciated but I made a pull request for this issue.

@mfitzp
Copy link
Member

mfitzp commented Jun 16, 2015

Very much appreciated 👍 I just need to find time to sit down and work through the PRs.

From what I've seen I don't imagine having any problems merging any of them but I need test against PyQt4, PySide and on different platforms (Windows, Linux) before accepting. They all do slightly weird things with the input/output of QSettings and it can cause issues.

@mfitzp
Copy link
Member

mfitzp commented Jun 16, 2015

Specific to this bug, the normal way I've dealt with this is to write custom handlers for the subclasses (you can pass them in when creating the manager). I have custom widgets that override signals and return different types, so it will need to ensure that the most specific possible handler is used. Perhaps test by type with fallback to isinstance?

@stlehmann
Copy link
Contributor Author

Perhaps test by type with fallback to isinstance?

I agree with you here. isinstance would return True for the base class and the inherited class and there is no way I know to tell which class is the more specific one. To check with type first would avoid this pitfall.

@stlehmann
Copy link
Contributor Author

Alright, I modified the code that now first the exact type is checked with type==. If there is no match another comparison is done with isinstance. I also made some tests for this use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants