[Development] Enum classes in signals?

[Sze Howe Koh]

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 {
>    Q_OBJECT
> public:
>    enum class E { E1, E2, E3 };
> signals:
>    void mySignal(E);
> };
>
> class B : public QObject {
>    Q_OBJECT
> 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.

+1

This is (kind of) illustrated at
http://doc.qt.io/qt-5/signalsandslots-syntaxes.html#type-checking-and-implicit-type-conversions
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.


Regards,
Sze-Howe