Hi Robin,
> So, your application code will be invoked when there is something to respond
> to (an event) - like a timer, socket activity, user
> input, etc. When that is done, the control has returned to Qt, and Qt goes
> back to sleeping, waiting for new events.
> At some point (I’m not sure
Hi Elvis,
On 27 Dec 2013, at 03:23, Elvis Lee(KwangWoong Lee)
wrote:
I’m looking for good way to handle objects which have called deleteLater.
According to what I understood until now, there are 2 ways to handle them.
One is making control return to the event loop. Another is calling
QCoreApplic
Hello.
I'm looking for good way to handle objects which have called deleteLater.
According to what I understood until now, there are 2 ways to handle them.
One is making control return to the event loop. Another is calling
QCoreApplication::sendPostedEvents(0, QEvent::DeferredDelete) explicit
On 26 December 2013 17:10, Mandeep Sandhu wrote:
> On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore wrote:
>> On 26 December 2013 13:11, Thiago Macieira wrote:
>>> On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
We could emit download progress for each intermediate req
On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore wrote:
> On 26 December 2013 13:11, Thiago Macieira wrote:
>> On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
>>> We could emit download progress for each intermediate request, but
>>> won't that look strange to a user as the
>
> There is no downloadProgress for any intermediate requests. We know that we're
> redirecting before we get the first byte of data out of the server. At that
> point, we can abandon the QHttpNetworkReply and move on to the next already.
The downloadProgress signal gives info about the received
On 26 December 2013 13:11, Thiago Macieira wrote:
> On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
>> We could emit download progress for each intermediate request, but
>> won't that look strange to a user as the bytes received & _possibly_
>> bytes total values will keep
On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
> We could emit download progress for each intermediate request, but
> won't that look strange to a user as the bytes received & _possibly_
> bytes total values will keep changing across these requests? Or is
> that acceptable
On 26 December 2013 12:45, Mandeep Sandhu wrote:
>>> Your thoughts?
>>
>> The download progress signal will have to be emitted for the
>> intermediate requests. Things like operation() and url() are stored in
>> the request object which can't be changed by the QNAM at all. If
>> people want all th
>> Your thoughts?
>
> The download progress signal will have to be emitted for the
> intermediate requests. Things like operation() and url() are stored in
> the request object which can't be changed by the QNAM at all. If
> people want all the details then they must implement their own
> redirecti
On 25 December 2013 07:54, Mandeep Sandhu wrote:
>>>
>>> 3. QNetworkReply stores both, the original as well as the final url.
>>
>> What about the intermediate ones in a chain of redirects?
>>
>
> Another question that springs to mind is what should the QNetworkReply
> object returned to the user
11 matches
Mail list logo
