Native Development

[georg]

Could someone kindly explain why this

QObject::connect(this->navigation_pane, SIGNAL(topChanged(Page*)), this, SLOT(onTopPageChanged(Page*)));

 does not work while this

QObject::connect(this->navigation_pane, SIGNAL(topChanged(bb::cascades::Page*)), this, SLOT(onTopPageChanged(bb::cascades::Page*)));

 does?

[strobejb]

It's a namespace issue -

In the top example the compiler does not understand what a Page is because it doesn't appear in the c++ global namespace. Page can be found in the bb::cascades namespace, which is why your second example works.

Just write:

using namespace bb::cascades;

in each .cpp file that you want to reference cascades objects and classes

[Zmey · Accepted solution]

MOC (meta-object compiler) doesn't take presence of namespaces into account. It compares argument types as strings. As the enums are defined as fully-qualified in Cascades headers they should also be fully-qualified in connect() calls. If they weren't fully-qualified clashes could occur for enums with same names in different classes.

From Qt docs:

Enums and Typedefs Must Be Fully Qualified for Signal and Slot Parameters

When checking the signatures of its arguments, QObject::connect() compares the data types literally. Thus, Alignment and Qt::Alignment are treated as two distinct types. To work around this limitation, make sure to fully qualify the data types when declaring signals and slots, and when establishing connections.

p.s. About the class names:

Names registered in qRegisterMetaType should be fully qualified otherwise they won’t be recognized by qvariant_cast. Cascades use fully-qualified class names so they should also be fully-qualified in signals declaration. 'using namespace' won't help with signal arguments, MOC will ignore it.

[strobejb]

Zmey has the correct answer!

[georg]

@strobejb Of cause I have "using namespace bb::cascades;" declared. Otherwise it would just result in a compile error. No, both versions compile, the difference is only noticable at runtime.