On 2/14/2020 11:19 PM, Tony Rietwyk wrote (in part):
I thought the whole point of the [=] in the lambda is to capture a shallow copy of the state required by the code within the lambda.
May I ask why you think that, or what you mean? I can't find any reference to [=] capturing
anything about
On 15/02/2020 7:01 am, Matthew Woehlke wrote:
On 07/02/2020 19.10, Tony Rietwyk wrote:
Does it work if you don't pass 'this' as the third argument to connect?
I never use that particular overload of connect. I usually pass the
lambda as the third argument.
That scares me. The third argument is
On Friday, 14 February 2020 11:13:24 PST Jason H wrote:
> After reviewing the QWebSocket spec ( https://tools.ietf.org/html/rfc6455 )
> text frames are supposed to be UTF-8 encoded, which would mean that
> QByteArray would be the proper class.
No, QString is the proper class because it's *text*. Q
On 07/02/2020 21.37, Jonathan Purol wrote:
> After manually removing every line of code to see when a MVCE would
> work, I found a loose `blockSignals(true)` flying around that was there
> from a debugging session.
`git diff`? Stuff like this is why you should use a VCS (it doesn't have
to be git)
On 07/02/2020 19.10, Tony Rietwyk wrote:
> Does it work if you don't pass 'this' as the third argument to connect?
> I never use that particular overload of connect. I usually pass the
> lambda as the third argument.
That scares me. The third argument is the context in which the slot
runs, i.e. t
After reviewing the QWebSocket spec ( https://tools.ietf.org/html/rfc6455 )
text frames are supposed to be UTF-8 encoded, which would mean that QByteArray
would be the proper class.
Now I'm having to toUtf8() all the things I receive, and QString() the ones I
send. I am sure this leads to some
