April 23, 2012

redlars redlars
Lab Rat
28 posts

Q_PROPERTY NOTIFY

 

Using Qt 4.7.1

Compiling this code generates the following error: NOTIFY signal ‘ValueChanged’ of property ‘MyValue’ does not exist in class MyWidget.

  1. class MyWidget : public MyBaseWidget, public QAxBindable
  2. {
  3.   Q_OBJECT
  4.   Q_PROPERTY(int MyValue READ getValue NOTIFY ValueChanged)
  5.  
  6. public:
  7.   MyWidget( QWidget *parent = 0, Qt::WindowFlags f = 0 );
  8.  
  9. //signals:
  10.   //void ValueChanged(int);
  11. };

Both the getValue method and ValueChanged signal are located in the base class.

Removing the slashes from the two last line makes the code compile.

Does Q_PROPERTY NOTIFY support using signals located in a base class? If no, are there any plans to add support and should the documentation (1) inform the developer of this limitation?

(1) – http://doc.qt.nokia.com/4.7-snapshot/properties.html

10 replies

April 23, 2012

sierdzio sierdzio
Area 51 Engineer
4816 posts

Not sure I ever ran into this. Have you tried using:

  1. Q_PROPERTY(int MyValue READ getValue NOTIFY MyBaseWidget::ValueChanged)

I am almost certain it will NOT work, but it’s still worth a try.

 Signature 

(Z(:^

April 23, 2012

redlars redlars
Lab Rat
28 posts

Thank you for the prompt reply.

Unfortunately it did not work. The meta-object compiler produced a parser error at MyBaseWidget on the modified Q_PROPERTY line.

April 23, 2012

Andre Andre
Robot Herder
6416 posts

While I think your question is very good, I fail to see a good use case for it. What do you need this functionality for? I think the three (getter, setter, notifyer, and possibly re-setter) are intimately tied together. In what case do you define them in different places in the hierarchy?

April 25, 2012

redlars redlars
Lab Rat
28 posts

We have stable widget implementation with a number of methods and signals.

  1. class MyWidget : public Widget
  2. {
  3.   Q_OBJECT
  4. public:
  5.   MyWidget(QWidget* parent = 0, Qt::WindowsFlags f = 0);
  6.   virtual ~MyWidget();
  7.  
  8.   void setFoo(int);
  9.   int  getFoo();
  10.  
  11. signals:
  12.   void fooChanged(int);
  13. };

At some point we needed to use this widget as an activeX (or activeQt) so we added the class below which did the trick. The Q_PROPERTY attributes act as an interface, therefore it made sense to have it as part of the MyWidgetActiveX class. Recently we used the NOTIFY attribute and discovered that it did not work like READ and WRITE attributes.

  1. class MyWidgetActiveX : public MyWidget, public QAxBindable
  2. {
  3.   Q_OBJECT
  4.   Q_PROPERTY(int MyValue READ getFoo WRITE setFoo)
  5.  
  6. public:
  7.   MyWidgetActiveX(QWidget* parent = 0, Qt::WindowsFlags f = 0);
  8.   virtual ~MyWidgetActiveX();
  9. };

April 25, 2012

Andre Andre
Robot Herder
6416 posts

Hmmm… OK. That is interesting. My first feeling would be: add the Q_PROPERTY to the MyWidget class instead. But if that’s not possible…

April 25, 2012

fcrochik fcrochik
Lab Rat
517 posts

You can just create a new signal on your MyWidget class (e.g. ValueChanged2), use it on the Q_PROPERTY declaration and on the class constructor connect the baseclass signal (ValueChanged) to the new signal…

It is not “ideal” but it should work…

 Signature 

Certified Specialist & Qt Ambassador Maemo, Meego, Symbian, Playbook, RaspberryPi, Desktop… Qt everywhere!

April 26, 2012

redlars redlars
Lab Rat
28 posts

andre: Agree, probably best solution. Will look into if that is possible in this case. Still find the limitation on NOTIFY strange given READ and WRITE do not have the limitation. Is there a technical reason for this?

fcrochik: Agree, works but not ideal.

April 26, 2012

ken536 ken536
Lab Rat
19 posts

Just is case:
Did you define getValue?

April 26, 2012

Andre Andre
Robot Herder
6416 posts

Yes, he did. See code sample above. It has been defined in the base class.

I think you should file a bugreport against moc on this. I don’t see why for the getter and setter using the implementation in the base class is allowed, but not for the signal.

April 26, 2012

alexisdm alexisdm
Lab Rat
141 posts

redlars wrote:
Is there a technical reason for this?

If you look at the code generated by the moc, you’ll see that there is only two changes when you add a NOTIFY field:
  • the property flag changes
  • the index of the notification signal is added to the meta data array.

Since the moc doesn’t really know which class your class inherits from, it can’t know the index of that signal in the base class. The existence of the signal would have to be tested dynamically at runtime rather than at compile time.

For the READ and WRITE fields, as the function names are used as is in the generated code, if the functions don’t exist, the compiler will generate an error, so the moc doesn’t have to do that check itself.

 
  ‹‹ How to change QWebView Audio level      QHelpEngine images ››

You must log in to post a reply. Not a member yet? Register here!