[Qt-interest] QThread problem

[prashant bhutani]

Okay, the signal-slotting did work.
Now, when the method for updation is being called,
it is clearing the previous TableWIdget and showing blank area until
other tab is clicked and I came back to process tab.

How to show the new data without making the user realize that something
happened?
I mean how to directly update the TableWidget without allowing blank window
to appear
and make user to switch tabs to come and see the new result?

Prashant Bhutani


On Wed, Nov 3, 2010 at 9:13 PM, Donal O'Connor <donaloconnor at gmail.com>wrote:

> It is started in the render method.
>
>
>
> On Wed, Nov 3, 2010 at 3:34 PM, prashant bhutani <
> prashantbhutani2008 at gmail.com> wrote:
>
>> Hi,
>>
>> Don't anyone think that in Mandlebort example thread "thread.start()" is
>> missing?
>> And without it how will the thread will execute?
>>
>> Prashant Bhutani
>>
>>
>>
>> On Wed, Nov 3, 2010 at 7:36 PM, <Oliver.Knoll at comit.ch> wrote:
>>
>>> On 2010-11-03 Joshua Joshua Wambua wrote:
>>>
>>> > Why don't you use a timer?
>>>
>>>
>>> Timers are lame! Real men use threads ;)
>>>
>>> No seriously, the Qt Mandelbrot examples/threads/mandelbrot nicely shows
>>> how to have a worker thread update the GUI with queued signals.
>>>
>>> Note the c'tor of the MandelbrotWidget:
>>>
>>> connect(&thread, SIGNAL(renderedImage(QImage,double)),
>>>            this, SLOT(updatePixmap(QImage,double)));
>>>
>>> The 5th parameter of connect() defaults to Qt::AutoConnection, and since
>>> the instances 'thread' and 'this' live in *different* threads (technically:
>>> when http://doc.qt.nokia.com/4.7/qobject.html#thread returns different
>>> values for the instances to be connected) this will evaluate to
>>> Qt::QueuedConnection.
>>>
>>> And that is what you want: the worker threads tells: "Hey, I got some new
>>> data, please render it". But since we all know that with Qt (and most other
>>> GUI frameworks) the widgets must not be updated within any other thread than
>>> the main thread (technically: where the QApplication instance "lives" in,
>>> aka "GUI thread"), the actual slot - which draws the widgets etc. - must be
>>> executed within the GUI thread. And that is exactly where the
>>> Qt::QueuedConnections are helpful!
>>>
>>> But keep in mind that Queued Connections don't help you in avoiding
>>> concurrent access to your data! Read about QSemaphore and Co.:
>>> http://doc.trolltech.com/4.7/threads.html
>>>
>>>
>>> Cheers, Oliver
>>> --
>>> Oliver Knoll
>>> Dipl. Informatik-Ing. ETH
>>> COMIT AG - ++41 79 520 95 22
>>>
>>>
>>>
>>> _______________________________________________
>>> Qt-interest mailing list
>>> Qt-interest at trolltech.com
>>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>>>
>>
>>
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20101103/4e787aaf/attachment.html