Q_PROPERTY NOTIFY

sierdzio

Not sure I ever ran into this. Have you tried using:
@
Q_PROPERTY(int MyValue READ getValue NOTIFY MyBaseWidget::ValueChanged)
@

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

redlars

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.

andre

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?

redlars

We have stable widget implementation with a number of methods and signals.
@
class MyWidget : public Widget
{
Q_OBJECT
public:
MyWidget(QWidget* parent = 0, Qt::WindowsFlags f = 0);
virtual ~MyWidget();

void setFoo(int);
int getFoo();

signals:
void fooChanged(int);
};
@

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.
@
class MyWidgetActiveX : public MyWidget, public QAxBindable
{
Q_OBJECT
Q_PROPERTY(int MyValue READ getFoo WRITE setFoo)

public:
MyWidgetActiveX(QWidget* parent = 0, Qt::WindowsFlags f = 0);
virtual ~MyWidgetActiveX();
};
@

andre

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...

fcrochik

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...

redlars

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.

ken536

Just is case:
Did you define getValue?

andre

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.

alexisdm

[quote author="redlars" date="1335443671"]Is there a technical reason for this?[/quote]
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.