Thiago Macieira schreef op 25-11-2013 18:06:
> On segunda-feira, 25 de novembro de 2013 17:28:38, André Somers wrote:
>> As you can connect to any method (as the slot part of the connection),
>> would this policy then not be needed for *all* methods, not just
>> signals? Or do I just misunderstand
On segunda-feira, 25 de novembro de 2013 17:28:38, André Somers wrote:
> As you can connect to any method (as the slot part of the connection),
> would this policy then not be needed for *all* methods, not just
> signals? Or do I just misunderstand the impact of the issue here?
The policy applie
Thiago Macieira schreef op 25-11-2013 17:23:
> On segunda-feira, 25 de novembro de 2013 17:00:41, André Somers wrote:
>> Thiago Macieira schreef op 25-11-2013 16:56:
>>> On segunda-feira, 25 de novembro de 2013 13:08:04, André Somers wrote:
Please note that this goes for *any* method that has
On segunda-feira, 25 de novembro de 2013 17:00:41, André Somers wrote:
> Thiago Macieira schreef op 25-11-2013 16:56:
> > On segunda-feira, 25 de novembro de 2013 13:08:04, André Somers wrote:
> >> Please note that this goes for *any* method that has an overload. And
> >> that any method that curre
Thiago Macieira schreef op 25-11-2013 16:56:
> On segunda-feira, 25 de novembro de 2013 13:08:04, André Somers wrote:
>> Please note that this goes for *any* method that has an overload. And
>> that any method that currently does not have an overload, may still get
>> one in the future. If you don'
On segunda-feira, 25 de novembro de 2013 13:08:04, André Somers wrote:
> Please note that this goes for *any* method that has an overload. And
> that any method that currently does not have an overload, may still get
> one in the future. If you don't want to run the risk of source
> incompatabil
Ola Røer Thorsen schreef op 25-11-2013 9:58:
> Got it, thanks.
>
> It's unfortunate that there is a method and a signal in
> QAbstractSocket witht the same name, but I guess we're stuck with that
> now.
>
Please note that this goes for *any* method that has an overload. And
that any method that
Il 25/11/2013 09:58, Ola Røer Thorsen ha scritto:
It's unfortunate that there is a method and a signal in QAbstractSocket
witht the same name, but I guess we're stuck with that now.
It's tricky coming up with the correct "signature" syntax if not having
seen it before. Maybe some example code c
Got it, thanks.
It's unfortunate that there is a method and a signal in QAbstractSocket
witht the same name, but I guess we're stuck with that now.
It's tricky coming up with the correct "signature" syntax if not having
seen it before. Maybe some example code could be added to this page here,
ht
On sexta-feira, 22 de novembro de 2013 16:56:47, Ola Røer Thorsen wrote:
> Is this a bug in Qt, or did I not use the correct syntax? I recon this has
> to do with QAbstractSocket having the error() function as well as an error
> signal.
You did not use the correct syntax.
The compiler told you th
Il 22/11/2013 16:56, Ola Røer Thorsen ha scritto:
fails, the compiler says
error: no matching function for call to 'MyClass::connect(QTcpSocket*&,
, MyClass* const, void
(MyClass::*)(QAbstractSocket::SocketError))'
This is a C++ problem -- means
that error() has overloads, and you need to
Hi all,
I've started using the new "Qt5" way of connecting signals and slots, to
get errors compile-time instead of runtime. Great stuff.
Here is one I struggle to connect. If you have a QTcpSocket, and want to
handle the error signal in a slot called tcpSocketError, a connect like
this:
connect
12 matches
Mail list logo
