Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
4.5.1
-
None
-
03daf059647c0a0222e8774b0a083f58c8e64934
Description
typedef QString FooBar; Q_DECLARE_METATYPE(FooBar); class MyClass : public QObject { Q_OBJECT signals: void test(FooBar baz); }; QSignalSpy *spy = new QSignalSpy(myClassPtr, SIGNAL(test(FooBar))); FooBar baz = "myValue"; emit myClassPtr->test(myValue); QList<QVariant> arguments = spy.takeFirst(); Q_ASSERT(arguments.at(0).type() == QMetaType::type("FooBar")); // okay FooBar test = arguments.at(0).value<FooBar>(); Q_ASSERT(test == "myValue"); // FAILS, test is == ""
The problem is that the following fails:
Q_ASSERT(qMetaTypeId<FooBar> == QMetaType::type("FooBar"));
It fails because the qMetaTypeId<FooBar> returns 0x0a: the metatype for QString. This makes sense because the FooBar type really is the same as QString.
But QMetaType::type("FooBar") does the lookup from Q_DECLARE_METATYPE and returns the user-type for it (in my case 0x0110).
So, I think the fix is to have Q_DECLARE_METATYPE check first if the true type is already registered or not. It is not possible to use the type name (as all we have is FooBar), and we can't use qMetaTypeId() because that won't work unless if it is already registered, which may or may not be true. So, I think the solution is to have QMetaType::registerType(name, deconstructor, constructor) check if the deconstructor/contructor match any already-registered types. If so, make it an alias of the already-registered type; otherwise register it as a new type.
The problem will affect more than just the signal-spy. It will affect any time that a QVariant is based on the type name ("FooBar") instead of using the actual type (T). So, perhaps queued signals and slots are affected?
Attachments
Issue Links
- depends on
-
QTBUG-937 When typedefing a known type and then registering it in the meta type system then it not always return the right id
- Closed