Connect() new style - how ?

never_ever

Hi,
I want to check sth in my app and I need to write connect in that new style that was introduced in Qt5.
I have connection SIGNAL-SLOT, but I want to change it :
@
connect(manager,SIGNAL(itemsReceived(QXmppDiscoveryIq)),this, SLOT(getList(QXmppDiscoveryIq)));
@
How it will look like in this new style?
Sth like this?
@
connect(manager, &QXmppDiscoveryManager::itemsReceived,this,&MyClass::getList);
@
What happens with signatures? If they are unnecessary? I write because the line above causes lots of errors and I don't know how exactly this code should look like.

GrahamL

What errors are you seeing?
Do you mean compilation errors or run time errors

never_ever

I had compilation errors, but I have already found out what I was doing wrong, but connection is still not working, quite likely that my signal is not emitted

IamSumit

hello never_ever,

connect function returns boolean value if it true it means everything is going in perfect way and if it is false then there is a problem in your connect() .
Check it out using qdebug();

never_ever

I checked it by using Q_ASSERT and it returns true.

JKSH

[quote author="never_ever" date="1392798422"]
@
connect(manager,SIGNAL(itemsReceived(QXmppDiscoveryIq)),this, SLOT(getList(QXmppDiscoveryIq)));
@
How it will look like in this new style?
Sth like this?
@
connect(manager, &QXmppDiscoveryManager::itemsReceived,this,&MyClass::getList);
@
[/quote]Hi, that looks correct.

[quote]What happens with signatures? If they are unnecessary?[/quote]They are unnecessary. This is the standard format for all C++ function pointers.[/quote]

[quote]but connection is still not working, quite likely that my signal is not emitted[/quote]Does it work with the old connection style?

Note that the new connection style doesn't work with default values.

never_ever

With old style connection it also doesn't work. I have tried to write it in new style, because I wanted to try if it would work with it.

"Default values"? Do you mean that my function getList shouldn't have arguments with default values? Because it doesn't.

JKSH

[quote author="never_ever" date="1392880251"]With old style connection it also doesn't work. I have tried to write it in new style, because I wanted to try if it would work with it.[/quote]Since connect() returns true, that means the connection was successful. It can work with both old and new styles.

That means one of two things:

Your signal isn't getting emitted, OR
Your signal is emitted, but your slot doesn't do what you think it does. (Did you put a qDebug() at the top of your slot to check that it's getting called?)

[quote]“Default values”? Do you mean that my function getList shouldn’t have arguments with default values? Because it doesn’t.[/quote]I don't think default values is your problem. But anyway, here's how it works:

Normally, your slot parameters must match your signal parameters. So if you have something like this, you can't connect them:
@
//signal
void mySignal();

// slot -- CANNOT connect
void mySlot(int param);
@

However, if your slot accepts default parameters, then you can connect them without any problems (the slot will just use the default value):
@
//signal
void mySignal();

// slot -- CAN connect
void mySlot(int param = 0);
@

kshots

Heh, if you really want to try something new, try using a lambda function instead of a slot, so you would write:

@connect(manager, &QXmppDiscoveryManager::itemsReceived, =
{ // write slot function in this block
});@

This de-clutters your project so you don't have slots all over the place that only get called from one location, and keeps the context all in one place. Really good for 1-line functions, although I find myself even putting complex functions in as lambdas, as long as it's only called from that one location. If you're careful, you can even take local variables into that slot (bearing in mind they will go out of scope when your function is done, so you may wish to only use pointers that were not deleted).

Note that in any case (with SIGNAL/SLOT macros, with function pointers, or with lambdas), you can omit the "this" pointer for the slot destination, as it is presumed that you are working with "this" as the destination whenever you omit the destination.

At any rate, back to the original topic: I see nothing wrong with what you wrote, it should connect properly. I'd suspect you're correct about the signal never being emitted. Some testing might be in order (perhaps subclassing the emitter and emitting the signal yourself?).