custom types for signal/slot arguments

[xtofl]

Hi.

In the Signals and Slots overview, I read that

Signals and slots can take any number of arguments of any type. They are completely type safe.

Actually trying that out, however, showed that a member function with a typedeffed argument is not recognized:

class IndexToEnum : public QObject {
   Q_OBJECT
...
   typedef QAudio::Mode mode;
signals:
    void modeChanged( QAudio::Mode mode );
    void modeChangedT( e mode );

class IndexToEnum : public QObject {
   Q_OBJECT
...
   typedef QAudio::Mode mode;
signals:
    void modeChanged( QAudio::Mode mode );
    void modeChangedT( e mode );

To copy to clipboard, switch view to plain text mode 

IndexToEnum* e = new IndexToEnum;
    // works just fine:
    connect( e, SIGNAL( modeChanged(QAudio::Mode) ), this, SLOT( modeChanged(QAudio::Mode) ) );
    // triggers "No such signal ModeEnum::modeChangedT(IndexToEnum::e)"
    connect( e, SIGNAL( modeChangedT(IndexToEnum::e) ), this, SLOT( modeChangedT(IndexToEnum::e) ) );

IndexToEnum* e = new IndexToEnum;
    // works just fine:
    connect( e, SIGNAL( modeChanged(QAudio::Mode) ), this, SLOT( modeChanged(QAudio::Mode) ) );
    // triggers "No such signal ModeEnum::modeChangedT(IndexToEnum::e)"
    connect( e, SIGNAL( modeChangedT(IndexToEnum::e) ), this, SLOT( modeChangedT(IndexToEnum::e) ) );

To copy to clipboard, switch view to plain text mode 

Note: I was actually tweaking the audiodevices demo, where I wanted to insert an index->enum convertor between the modeBox and the AudioTest object.

Is this improper use of the signal/slot mechanism? Are there any other restrictions on the argument types?