[Development] Enum classes in signals?

Sze Howe Koh szehowe.koh at gmail.com
Wed Feb 6 14:50:32 CET 2019

On Wed, 6 Feb 2019 at 12:43, Giuseppe D'Angelo via Development
<development at qt-project.org> wrote:
> Il 05/02/19 18:16, Dmitriy Purgin ha scritto:
> > I couldn't figure out the exact combination but as far as I remember, if
> > you have namespaced code, you have to always fully qualify the enum
> > class parameters in signals and slots.
> This is actually also the case for enums and enum classes. For instance,
> consider
> class A : public QObject {
> public:
>    enum class E { E1, E2, E3 };
> signals:
>    void mySignal(E);
> };
> class B : public QObject {
> public slots:
>    void mySlot(A::E);
> };
> This code compiles just fine, but you will NOT be able to connect
> mySignal1 to mySlot using SIGNAL/SLOT.
> Doing it like this
>    connect(a, SIGNAL(mySignal(E)), b, SLOT(mySlot(A::E)));
> won't work because the argument lists don't match (this connect version
> compares the parameter lists _as strings_, and obviously "E" is
> different from "A::E").
> Connecting it like this
>    connect(a, SIGNAL(mySignal(A::E)), b, SLOT(mySlot(A::E)));
> will not find mySignal in A, because the lookup will search for a
> function with that signature _spelled exactly that way in the source
> code_. Such a function is not there; the source code spells "E" as
> parameter type, not "A::E".
> The solution hence is to declare the signal with an A::E parameter.


This is (kind of) illustrated at
using QAudio::State as an example.

The article also shows a use-case that cannot be supported by PMF
connections, namely making connections between C++ and QML. This is
why the string-based syntax must not be deprecated.


More information about the Development mailing list