[PyKDE] Problem resolving widget's class

[Fredrik Juhlin]

On Monday 01 November 2004 17.08, Phil Thompson wrote:
> > Hi,
> >
> > We're having some difficult-to-reproduce problems with SIP/PyQt. At
> > times, widgets don't have their right class, i.e. a widget we know to be
> > a QLabel,
> > QHeader etc. is instead just a QWidget, which of course breaks code that
> > tries to access for instance QLabel methods.
> >
> > From what we can tell though, it only happens to widgets that comes from
> > "C++
> > land", so to speak. That is, widgets that are created by QWidgetFactory,
> > the
> > listbox you get when calling QComboBox.listBox(), the header from
> > QListView.header() etc. This has made us draw the conclusion that there's
> > most likely something wrong in SIP?
> >
> > We've tried to come up with some kind of way to reproduce it in an
> > orderly fashion, but it just can't be done. The only thing we've found so
> > far is that
> > it seems to be more prone to occur on Windows XP than on Linux, but it
> > still
> > occurs on both platforms.
> >
> > We're using Python 2.3, SIP 4.1.1, PyQt 3.13 and Qt 3.3.3.
> >
> > Any help would be appreciated!
>
> I assume it doesn't happen with every widget created in "C++ land" - as
> that would be easy to demonstrate. Is there any pattern to when it does
> happen?
Unfortunately, no. It seems to occur randomly. Let me give you a couple of 
example scenarios:

We have a custom widget that is basically a subclassed QWidgetStack with
two pages, one containing a QComboBox and the other containing a QLineEdit.
At some point, we access the listBox() method of the QComboBox.
This custom widget is one that we very frequently use for our application. 
Most of the time it works just fine, but occasionally the return value of 
listBox() isn't a QlistBox but a QWidget. By occasionally I mean that we 
probably instantiate this widget class 100s of times without a problem for 
every time we do get the error.

Also, we use qtui to create forms from .ui-files. These forms contain our own 
custom widgets like the one I described above, so we have our own 
QWidgetFactory to handle the instantiation of those widgets. But we also use 
standard Qt widgets in these forms, such as QLabel, and these are 
instantiated without the interference of our widget-creating code. We do, 
however, seek the QLabels out in order to set the text on them. We find them 
by using a naming scheme, where every label is named "label_<something>". 
Again, most of the time this works fine, but every now and then the widget 
isn't a QLabel, but a QWidget, meaning that the setText() call fails with an 
AttributeError. (Btw, since we identify QLabels by their name rather than 
class, we did make sure that we hadn't accidentally named a non-QLabel  
"label_<something>".)

My third and final example is one of our custom widgets that inherit 
QListView. at some point we call the header() method to access the QHeader. 
We do this typically to rearrange the columns in accordance with the user's 
preferences. Again, this code works fine most of the time, but at times the 
header widget is a QWidget, not a QHeader.

It's not like this only happens when we do something unusual with the app. In 
the form scenario described above, we can instantiate the same form over and 
over without the error occuring, only to have the error occur in the same 
kind of situation as it has worked previously.

> SIP uses the MOC generated class name to determine what Python type to
> give the C++ instance, so missing Q_OBJECT in a C++ class or a bad C++
> pointer would cause problems - but those are unlikely to be issues in the
> Qt library itself.
>
> Is it a pure PyQt application, or are you using other wrapped libraries?
Nothing else that is wrapped by SIP, no. We do use the PyOpenSSL bindings, but 
it seems unlikely that they would interfere with SIP or PyQt, doesn't it?

//Fredrik